European commercial vehicle OEMs face a practical GSR challenge: each safety function must work in the vehicle, but the vehicle must also remain manageable to validate, build and update. Streamax ESS2.0 is a single-domain GSR full-stack solution designed to combine required safety functions, Advanced Emergency Braking System (AEBS) capability and Around View Monitoring (AVM) on one vehicle platform. It helps engineering teams replace fragmented integration work with a more scalable path to European type-approval preparation. For commercial vehicle safety programmes, the architecture must support both the function and the evidence behind it.
EU compliance is now an architecture decision
The EU General Safety Regulation, Regulation (EU) 2019/2144, sets type-approval requirements for vehicle safety and vulnerable-road-user protection. Its application dates differ by requirement and vehicle category, but the direction is clear: commercial vehicle programmes need to plan functions such as intelligent speed assistance, driver warning, blind-spot and moving-off information from the start.
That is why compliance cannot be treated as a late-stage installation exercise. Multiple standalone ECUs, cameras and wiring harnesses can create duplicated integration, calibration and validation work. They also make it harder to trace how a change in one function affects the rest of the vehicle.
The design choice also affects approval evidence. When hardware, software and vehicle interfaces are owned by different suppliers, an OEM must still show how versions, interfaces and changes are controlled on the finished vehicle. A consistent technical baseline can give programme teams a clearer record of what needs to be evaluated after a change. It does not replace testing or approval work, but it can make the scope of that work easier to define.
For M2, M3, N2 and N3 programmes, the better question is not, "Which device satisfies this requirement?" It is, "Can this vehicle architecture support the required functions, evidence and updates across its lifecycle?"
What UN R131 means for AEBS planning
UN R131 governs AEBS for relevant heavy commercial vehicles. The regulation's updated direction extends attention beyond simple high-speed, rear-end cases toward more demanding scenarios, including moving vehicles, stationary vehicles and crossing pedestrians. In practice, that raises the importance of perception, risk assessment, warning logic, braking coordination and vehicle-level validation.
An AEBS capability therefore cannot be evaluated only by its forward sensor. OEM teams need to consider the full safety chain: what the vehicle detects, when it warns, when it requests braking, how the braking system responds and how the system is validated on the final vehicle. Real-world low light, urban stop-and-go traffic and false-braking control should be part of that conversation.
For an OEM, this is a vehicle-integration question as much as an algorithm question. Camera placement, signal latency, in-vehicle communication, brake-request interfaces and calibration can all affect the final behaviour of an advanced emergency braking system. If one part changes during development, the team needs a defined way to assess the impact on connected functions and test evidence. A shared domain-controller baseline cannot remove every interface, but it can make those dependencies more visible before approval testing.
Plan R131, R155 and R156 together
UN R131, R155 and R156 address different parts of the vehicle programme, but they meet in the electronic architecture. Safety functions such as Blind Spot Information System (BSIS) also need clearly defined interfaces with the vehicle and related warning functions.
UN R131: AEBS performance and the integration needed for type approval.
UN R155: a Cyber Security Management System (CSMS) that manages cyber risk throughout the vehicle lifecycle.
UN R156: a Software Update Management System (SUMS) and controls for identifying, validating and deploying software updates.
R155 and R156 do not mean that an onboard controller alone makes a vehicle compliant. They require manufacturer processes, governance and evidence. However, an architecture that supports controlled software releases, clear interfaces and traceability gives those processes a more practical foundation. UNECE describes R155 as a risk-based cybersecurity framework and R156 as a framework for software-update management in its official overview of the regulations.
How ESS2.0 supports a single-domain approach
ESS2.0 consolidates GSR-related functions, AEBS and AVM on a high-performance domain controller. It is designed to share cameras, computing resources and in-vehicle communication interfaces across functions, rather than installing separate hardware for every requirement.
For OEM engineering teams, that can mean fewer duplicated sensors and ECUs, a simpler wiring and packaging task, and one technical baseline for function integration. The platform also combines AI vision with Streamax Blacklight low-light enhancement to support vehicle, pedestrian, blind-spot and driver-state detection in challenging light conditions.
This approach is relevant across buses, coaches and trucks because the physical packaging problem changes with the vehicle, while the need for a clear safety architecture remains. A programme may need different camera locations, warning strategies or CAN integration, but it benefits from reusing a common approach to computing, interfaces and software version control where the vehicle design allows it.
Its OTA capability, reserved computing capacity and extensible interfaces are intended to support later function updates, such as additional driver-warning applications, AVM or adaptive-cruise applications. This does not remove the need for vehicle-specific verification or approval. It gives OEMs a platform on which those activities can be planned with less fragmentation.
From compliance checklist to vehicle platform
The advantage of a single-domain approach is not that one product can guarantee every approval outcome. Type approval remains vehicle-specific, and the OEM remains responsible for the final vehicle, its CSMS and its SUMS. The advantage is that GSR functions, AEBS, cybersecurity and update planning can begin from a shared architecture instead of a collection of disconnected subsystems.
Streamax's broader OEM GSR compliance and vehicle safety solution covers the related BSIS, MOIS, ISA, DDAW, ADDW, LDW, AEBS, cybersecurity and software-update landscape for commercial vehicle programmes. For the complementary post-crash layer, see how a commercial vehicle EDR under UN R169 fits into an OEM safety architecture.
For European OEMs, ESS2.0 is a way to make compliance planning more coherent: one domain controller, shared sensing and computing resources, and a platform designed to evolve as vehicle requirements change.
