JT 1076 sets the rules for the video box in the cab. JT 1077 sets them for the platform at the centre. They are two halves of one monitoring system, split on purpose so the parts can be bought from different makers.
A regulated video system has two ends. One is the terminal in the vehicle, the recorder and its cameras. The other is the platform at the operator or the regulator, the software that watches and stores. China writes a separate standard for each end. JT/T 1076 covers the on-board video terminal. JT/T 1077 covers the video platform. Both came out in 2016, alongside the JT/T 1078 protocol that lets the two talk.
There is a reason for that split, one that shapes the whole arrangement. A single standard for the entire system would tie each maker’s terminal to its own platform. The fragmentation a common framework was meant to end would creep straight back in. By drawing a line between the box and the centre, the standards let one company build terminals and another build platforms, with the protocol guaranteeing they meet in the middle. A fleet can pair a terminal from one supplier with a platform from another, as long as both sit inside the framework.
Reading the two standards together is the way to see the shape of the system, then to read a datasheet without being misled. The two device standards split the system between the box on the vehicle and the centre it reports to, with the protocol covering the words that pass between. Held apart like that, each standard stays attached to the conditions its own end faces; a claim of compliance only means something once it is pinned to one of the three documents.
The system runs as a line from the camera to the control room. At one end the terminal records the cameras and holds the footage, answering the platform’s requests over the cellular link. At the far end the platform takes those streams in and keeps the record a regulator can later audit. Between the two runs the protocol. JT 1076 governs the near end and JT 1077 the far end, with JT 1078 carrying the conversation across the gap between them.
None of the three is the whole answer on its own. A terminal built to JT 1076 with no platform to report to has nowhere to send what it records. A platform built to JT 1077 with no terminals to watch has nothing to display. The framework works only when both ends are built to their own standard and both speak the shared protocol, which is why a regulator mandates the whole set together. The two device standards are halves of a pair, written to be read together.
1076 reaches the hardware in the cab; 1077 reaches the platform software.
JT 1076 is the standard for the on-board video terminal. It lays down what the device on the vehicle has to be, from the general requirements through its functions and performance to the way it is installed and tested. It reaches the terminal host, the cameras and the other peripherals that hang off it, so the whole recording end of the system answers to one document.
A buyer pictures the functional side first. The terminal has to record its cameras and hold the footage for a defined retention. It manages the channels and raises the alarms the safety case needs. The channels themselves follow a fixed logical map, a numbered table every compliant terminal shares, which the active-safety profiles extend upward, 0x64 carrying the forward ADAS view and 0x65 the driver-facing camera. A platform reading a stream knows which view a number carries before a pixel decodes, on any make of terminal, which is what lets a provincial video wall mix suppliers without a per-brand translation layer. All of that it then serves to the platform on demand. The performance side is quieter and harder to read off a page. It covers how the device behaves under the conditions a vehicle imposes, from the load of encoding several cameras at once to the way it holds a recording, and its timing, when power and signal come and go. A terminal can tick every functional box and still fail the performance ones the first hot afternoon it spends in a cab.
Installation is part of the standard for a plain reason. A terminal mounted wrong, with a camera aimed poorly or a cable run that fails to a knock, meets none of its functional promises in service. So JT 1076 carries installation requirements alongside the device ones, plus the test methods that check a terminal against the whole list. The document runs in the order a certifier uses it, general requirements, functions, performance, installation, then the test methods that exercise each, so type testing walks the text front to back. A device that passes those tests goes onto an approved-product list, from there onto a regulated vehicle. A fleet buying for a two-passenger-class or hazardous route cannot fit any recorder it likes; it fits one certified against JT 1076, because the vehicle’s right to run depends on the device being on that list at all.
The retention requirement is one to read carefully. The standard bears on how long footage has to survive on the device, which drives the storage a terminal needs and the rate at which old recording is overwritten. Size the retention against the busiest route and the card holds the evidence an investigation might still want; cut it short to save cost; the clip an inquiry asks for a month later is already gone. The functional line is a short one. The storage decision behind it is among the larger choices in fitting a fleet.
What JT 1076 is setting a bar for, underneath the functional list, is survival in a hostile place. The terminal is embedded hardware bolted into a vehicle. The cab heat climbs past anything an office machine sees. The vibration works every connector loose over time. The supply voltage sags and spikes as the engine cranks. It records to a card that has to take years of continuous writing without dropping a frame the day an alarm needs it. This is where a cheap terminal fails.
The harder demands are the ones that do not show on a feature list. Encoding several cameras at full rate while also cutting sub streams for the platform is a steady processing load the box carries every minute it runs. Holding a clean recording across a power cut means a clip file pre-allocated and flushed, so a sudden loss leaves a playable file on the card the next morning. Keeping time when the link drops means the timestamps still line up when the footage is pulled a week later. These are the things JT 1076 obliges a terminal to do. The test methods exist because datasheet claims need checking against a summer cab.
The test methods make the standard enforceable. A terminal is checked against the performance list under the conditions that break cheap hardware, the heat and vibration of a working vehicle chief among them, with several cameras encoding at once. A device that passes on a bench at room temperature and folds in a hot cab has not met JT 1076, whatever its datasheet claims; the methods exist to catch that gap before the vehicle carries it onto the road. Certification against them is what puts a terminal on the approved-product list a regulated fleet has to buy from.
JT 1077 is the matching standard for the video platform, the software end the terminals report to. Where 1076 pins down the box, 1077 pins down the centre, setting out what a platform has to be able to do with the video and the alarms once they arrive. It is the standard a provincial monitoring platform is built against. It is also the one a private operator’s system has to meet to slot into the regulated framework.
The platform side carries its own weight of requirement. It has to take live streams from many vehicles at once and keep the recorded footage they send. The alarm attachments arrive as evidence to hold and index. All of that has to reach operators in a form they can work. It has to manage users and their permissions, so the right people see the right vehicles. And it has to connect upward, passing data to a higher-level platform where the regulator sits above the operator, so a province sees across the fleets beneath it. A platform that drops streams under load, or loses an alarm clip, fails the people relying on it as surely as a bad terminal does.
The centre is the half of the system a fleet owner depends on and rarely sees. When the platform belongs to the regulator, it gathers every compliant terminal in the province into one place. When it belongs to an operator, it carries that operator’s own vehicles and hands the required data up the chain without a custom bridge for each link. Both cases hold the platform to a written standard of its own.
An operator may need the footage from one vehicle, on one afternoon three months back, found among the records of a whole fleet before an investigation goes cold. Retrieval is where a platform proves its value, with raw storage the easy part. JT 1077 holds the platform to making that footage findable, down to the right thirty seconds among a fleet’s months of records.
The upward connection is easy to miss. A regulator does not watch every vehicle directly. The operators run their own platforms, which pass the required data up to the regulator’s platform above them. JT 1077 sets what a platform has to send up and how, so the layer above sees across the operators without each one building a private bridge. A province-wide view is possible only because every platform underneath speaks the same upward language the standard defines.
The platform faces a problem the terminal never meets: scale. One terminal watches one vehicle. One platform may watch tens of thousands, each streaming when asked, each able to raise an alarm at any moment, each holding footage a query might reach for without warning. A platform that demos cleanly on ten vehicles can still fail on the province it was built to serve. JT 1077 exists in part to set a bar the centre has to clear under that weight.
The storage problem alone is large. Alarm attachments arrive as files that have to be kept, indexed and findable months later, tied to the vehicle and the event that produced them. The live wall has to stay responsive while all of that lands in the background. The connection upward to a higher platform has to carry the right data without flooding it. None of this is the terminal’s world, which is exactly why it is a separate standard, written for a separate kind of engineering, by and for a different sort of supplier.
A continuity demand runs under all of it that a terminal never carries. A terminal that reboots loses a few seconds from one vehicle, recoverable from the card. A platform that goes down takes the live view of a whole fleet with it, along with the records riding on it, leaving no card at the centre to fall back on. So the centre carries redundancy the cab has no need of, the spare capacity and failover that sit idle on a quiet afternoon and carry the fleet through the first hour a server fails mid-shift. Sizing that headroom against the fleet at its busiest is a demand JT 1077 places on an operator that no terminal specification raises.
Concurrency is the common failure point at the centre. A platform sized for the average load meets a rush when a depot full of vehicles wakes together, all registering, all ready to stream at once. A design that looked fine on a slow afternoon stalls. JT 1077 sets a bar the centre has to hold at the peak it will meet. The peak load arrives when the whole fleet moves together, in the same hours the operator watches hardest. A platform sized below that peak fails on the day the operator needs it.
JT 1078 is the protocol that lets the two ends meet. JT 1076 says the terminal must stream a camera on request. JT 1077 says the platform must be able to ask for one. JT 1078 is the agreed wording of the request and the answer, so a terminal built to 1076 and a platform built to 1077 do not have to come from the same company to understand each other. The protocol is the contract that turns two separately built ends into one working system.
This is why the three standards are read as a set. A terminal can meet every functional line of JT 1076 and still be useless if it speaks a private protocol no platform understands. JT 1078 closes that gap by fixing the language; the terminal and platform standards lean on it to make their own requirements reachable from the other side. Without the protocol in the middle, 1076 and 1077 would describe two halves with no way to join them.
Beneath the video standards runs JT/T 808, the older protocol that carries a terminal’s registration, position, status and basic alarms to the platform. The video framework assumes 808 is already there. A terminal opens its 808 session first, then the video traffic of JT 1078 rides over the link that session has established. So a complete commercial-vehicle terminal answers to a stack of standards at once, with 808 at the base, JT 1078 for the media, and JT 1076 setting what the device built on top of them has to be. The platform it reports to is built to JT 1077, reading the same 808 and 1078 from its own side. A terminal that implements only one layer of this stack is not, on its own, a terminal a regulated fleet can put on the road.
The reason for the four-standard split is the framework’s core idea. A monitoring system has two unlike jobs at its two ends. The terminal is embedded hardware in a hostile place, exposed to heat, vibration and a patchy cellular link. The platform is server software in a data centre, sized for scale and storage. The skills behind the two have almost nothing in common, the suppliers are different companies; even the rhythms differ. A terminal is approved once and then held still for years in the field. A platform is patched and grown month by month. Bundling them into a single standard would force one supplier to do both, or force every pairing to be tested as a unit; either way the fleet owner is the one who loses. Each maker would end up doing the other’s job badly. The procurement sides differ as well. A terminal contract is a hardware purchase with a delivery date. A platform contract is a service with uptime terms and a support rota. The two live in different departments at the buyer too. A single combined contract would mix the two beyond untangling. Splitting the framework into a terminal standard, a platform standard and a protocol between them is separation of concerns written into regulation. The terminal maker builds to JT 1076 and implements JT 1078, then stops worrying about who runs the platform. The platform maker builds to JT 1077 and implements JT 1078, with the same independence on its side. The protocol guarantees any compliant box and any compliant platform will work together, so the buyer mixes and matches on price and quality, the province standing up one platform that reaches a fleet of mixed makes. The cost saved is the cost of lock-in, which over a fleet of thousands of vehicles, replaced on different cycles from different budgets, is the difference the framework was written to capture. That gap in pace would justify the divide on its own. A vehicle cannot chase firmware that shifts under it, so a terminal is settled before it ships and then left alone, as the centre keeps changing under the operator’s hands every week it runs. One standard laid over both would tie the slow device to the fast service. Split apart, each keeps its own clock. That independence is what the split buys: the box and the centre each built well on its own terms, by the supplier who knows that half, answering for it alone.
The same split shows in how the standards are revised. A change to what a platform must store touches JT 1077 alone, leaving every terminal already in the field untouched. A new terminal function touches JT 1076 without forcing a platform rebuild. The protocol moves slowest of the three, since a change there would break the contract both ends depend on, so it is held stable while the two device standards evolve at their own pace on either side of it.
The arrangement also tells a buyer where to look. A terminal is certified against JT 1076 and the protocol, which leaves JT 1077 as the platform’s business and none of the terminal’s. A platform answers for the reverse pair. Treating the two as interchangeable badges is the error to guard against, the one that puts a platform certificate on a terminal datasheet.
The clearest sign that 1076 and 1077 are built for different worlds is how each one is checked. A terminal under JT 1076 faces type testing. A physical sample goes onto a bench and into an environmental chamber, put through the heat, the vibration and the voltage swing it will meet in service, with the functional checks run alongside. The outcome is a device approved as a model. Every unit built to that model then carries the approval, which is what lets a fleet trust an entry on an approved-product list without testing each box itself.
A platform cannot be tested that way, because no chamber holds a piece of software. JT 1077 is checked against capability: whether the platform takes the load it claims, keeps the records it must, and passes the required data up the chain. The proof is closer to a conformance assessment of a running system than a bench test of a sealed unit. One regime tests a thing you can hold in a fixture, clause by clause against JT 1076’s own test-method chapter; the other tests a service that has to keep standing as it works.
The difference reaches the buyer in a concrete way. A terminal’s approval rides with the model, fixed at the point of certification and good until the model changes. A platform’s standing is tied to the live deployment, a thing that grows and is patched, so it is judged as it runs, with the judgement repeated through its life. To read a compliance claim is to ask which kind of proof sits behind it: a certificate for a model of box, fixed at certification, or an assessment of a platform that has to stay compliant every day it is up. The two ends differ all the way down, including in how each one is proven.
For a fleet buying terminals, the document to hold the device against is JT 1076, paired with JT 1078 for the protocol. A terminal that meets both will record what it should and report it in a language the platform understands. A claim of JT 1077 compliance printed on a terminal datasheet has put the platform’s standard on the wrong device; seeing it quoted there is a sign the supplier is quoting badges where a plain statement of what the box meets belongs. A tender for the centre can carry the reverse error, a platform bid offering terminal certificates at a software evaluation.
An operator standing up a platform reads it the other way round, holding the system against JT 1077, again with JT 1078 for the protocol. What protects a buyer on either side is knowing which half the purchase sits in, judging it by its own document: the terminal by 1076, the platform by 1077. A buyer who confuses the two grades a recorder against the centre’s rulebook, or a platform against the box’s, trusting a badge that was never that device’s to claim. Kept straight, the framework gives back what it was written for, a fleet whose two ends can be sourced apart and swapped one at a time.
The framework asks a little more homework of the buyer than a single all-in-one purchase would, since two standards have to be checked and a join proven between them. In return, either end can change without scrapping the other. Each supplier answers for the part it does well. A fleet of mixed makes runs under one platform. The replacement cycles stay independent on each side. For an operator whose vehicles run for years and whose parts are replaced on different clocks and budgets that never line up, that trade is the one to make.
JT/T 1076 sets the technical requirements for the on-board video terminal, the recorder and cameras in the vehicle. JT/T 1077 sets them for the video platform, the software at the centre the terminals report to. One governs the box, the other governs the centre; the two are halves of one monitoring system written to be read together.
JT 1078 is the communication protocol that lets the two ends talk, riding on JT/T 808 for registration, position and basic messages. JT 1076 says what the terminal must do, JT 1077 says what the platform must do; JT 1078 fixes the language they use together. A complete terminal sits on the 808 and 1078 stack and is built to 1076; the platform is built to 1077.
A terminal is built and certified against JT 1076 for the device and JT 1078 for the protocol. It is not certified against JT 1077, which is the platform’s standard. A JT 1077 claim on a terminal datasheet is a category error and a reason to look more closely at the rest of the specification.
A platform is built against JT 1077 for its own requirements and JT 1078 for the protocol it speaks to terminals. It has to take many live streams at once, store and retrieve footage, hold alarm attachments as evidence, manage users, connect upward to a higher platform, and stay responsive under the load of a whole province of vehicles.
The terminal is rugged embedded hardware in a vehicle; the platform is server software in a data centre. Splitting them into a terminal standard, a platform standard and a protocol lets different companies build each, with the protocol guaranteeing they work together. The fleet can mix suppliers; a province can run one platform across a fleet of mixed makes.
Not on its own. Two compliant builds still have to be docked on a working link, since a standard leaves room for interpretation. The live view, alarm attachment and playback all have to be proven end to end on the real platform a fleet uses before a vehicle counts as monitored.
