Managing Today’s Advanced Vehicle Networks Design Challenges

Today’s automotive electrical and electronic (E/E) architectures are highly complex, with the functionality of many vehicle features distributed across multiple discrete ECUs. The ECUs, sensors and actuators are not all directly connected, and much of the data communication occurs across networks, often through gateways over several networks. Modern E/E architectures are formally organized around functional domains, increasingly with domain computers or controllers acting as a centralized compute, absorbing much of the higher-level functions for that domain.

Increasing use of service-oriented architectures (SOA) enabled by Ethernet networking allow principles from the information technology (IT) domain to be re-used in automotive applications. The main evolution of SOA is the move from thinking about discrete signals to services, which provide multiple related signals which subscribe to services appropriate to their functional needs.

SOA occurs in parallel with changes to the physical architecture. Computing power is increasingly centralized, with domain ECUs reorganized into a zonal layout. Some OEMs and integrators opt for high computing power in the zonal ECUs that reside near the sensors and actuators, while others keep them to relatively simple gateways. Also, moving away from functional domains cascades high integrity requirements into more ECUs across the architecture. These architectures can streamline the scalability of functionality, with processing and memory headroom provisioned only in the central compute unit. Centralized or zonal architectures also help reduce harness mass and lower bill-of-material (BoM) costs to the OEM. The speed of this transition is variable across organizations, regions, and vehicle market sectors (figure 1).

Fig. 1: Centralized vs. zonal architectures.

Increasingly, the instrument cluster, central display(s), and heads-up display (HUD) are part of one integrated system, an extension of the driver information and infotainment systems. With more information in the instrument cluster with functional safety considerations, several partitions are still required on the compute platforms hosting these functions; such partitions may be separate processors or merely separate cores. These systems may have discrete LEDs, switches and other peripherals connected to fully meet their requirements, though traditional automotive vehicle control switchgear is often connected to a body controller or gateway.

Besides the media functions hosted in the infotainment portion of this system, other pieces of critical driver information range from vehicle speed and faults through driving modes, ice warnings, navigation directions, estimated range, and more. Some OEMs call the cluster a ‘combination meter’, bringing together what were once multiple instrumentation gauges, warning lights, and trip computer elements into one system. Every time functions are consolidated, new functions are added in new components or ECUs, from trip computers through to clocks, temperature gauges, and ice warnings (figure 2).

Fig. 2: An example subset of signal flows in a vehicle architecture.

For the automotive network designer, each design decision has an impact on the full system and should be considered at the time of design, allowing system testing later in the process to confirm correct behavior rather than uncover issues requiring design iterations. This article will provide an overview of critical areas for vehicle networks design, and a solution to manage challenges to meet key vehicle design requirements.

Network load and gateway load

For CAN-to-CAN gateways, network designers could choose between gatewaying whole frames of signals, or each signal individually, re-packed into a new frame. This simple trade-off between more processing at the gateway or less-efficient use of network bandwidth, exists today. AUTOSAR provides protocol data units (PDUs) as a design element for gatewaying between different network technologies while preserving the option of reading out individual signals and repacking them into a new PDU.

However, the designer may need to consider how the gateway will trigger the sending of the gatewayed data it’s forwarding, which influences the overall latency across the system. This is often constrained by re-use of existing ECUs or frame and PDU designs that support an integration with a supplier across multiple vehicle programs.

Some OEMs prefer using an existing library of pre-designed network messages and frame packing to support ECU re-use without changes. Using a standardized protocol like SAE J1939 (for heavy duty and off-road vehicles) enables the reliable connection of vehicles and equipment of different brands. Both approaches reduce the optimization scope, but it won’t reduce the performance and behavioral considerations of the design.

Network designers follow specific OEM-defined design rules for many technical details of the system, such as the prioritization or scheduling of each network technology. LIN and FlexRay are time-triggered networks with a schedule. CAN uses an arbitration mechanism based on the frame ID, reserved for different types of payloads including functional and network management to run most networks, and data for service and diagnostics. Higher priority is often assigned to data that would affect vehicle functions with variable jitter.

Ethernet and switches

Ethernet design, including switch configuration, expands from the network traffic of a single domain to include more general vehicle data, e.g. data passing between traditional networks and Ethernet, as a backbone between functional domain controllers for full system considerations. Ethernet adds another set of network behaviors and a more complex set of standards and protocols. However, these are more scalable than specialized automotive networks, with the same communication software in use regardless of Ethernet physical layer type, making updates easier. Ethernet networks can interoperate at multiple baud rates and be used across a large section of the vehicle, reducing the technological complexity over time. FlexRay and high-baud-rate CAN have a seemingly ever-reducing set of use-cases for which they are the ideal solution (see table 1).

Ethernet networks introduce additional configuration options for the network designer. Protocols, methods, and elements of different levels ensure that priority data, signals, and services are available in a timely manner while allowing multiple types of data on the same physical network. Meanwhile, virtual local area networks (VLANs) segregate different types of data, and allow prioritization of various data types, can be limited (in terms of bandwidth utilization), and even disabled. A specific VLAN may be used to implement software updates, allowing bandwidth regulation utilized for specific functions, depending on the vehicle status or mode.

Audio visual bridging (AVB), created to add specific shaping or prioritization of audio and visual data flows on Ethernet networks, ensure that audio and visual data could be sent across the network without pops, crackles, or other distortions due to variable data rates. AVB, adopted by early automotive Ethernet users in conjunction with scalable service-oriented middleware over IP (SOME/IP) and service discovery (SD), enables SOA communication. Time sensitive networking (TSN) is an AVB development specifically for functions and use-cases that have high integrity requirements. TSN extends some of the elements of AVB, while also adding others that were not available before.

AUTOSAR has either directly included or supported the above technologies and standards as they have been needed. Standards and functionality needed by both Classic and Adaptive versions of AUTOSAR are standardized in the Foundation standard, ensuring compatibility and consistency.

Functional safety

Network designers have been designing with functional safety in mind for many years now, and in most cases the mechanisms used are well understood. The larger data elements and objects used with higher levels of driver assistance and automation have added updated mechanisms or schemas in recent AUTOSAR releases.

The conventional approach with networks is to treat them as quality measures (QM), as defined in ISO 26262, as a mechanism, and thus add elements to the design to validate that the data is being received regularly and accurately. Increasing system integrity requirements now demand redundant routings for some data, but this is a system-level design consideration, encountered as additional design rules.

Data that carries a potential safety consequence if incorrect or missing primarily receives end-to end (E2E) protection, whereby a group of signals are packaged in a common message or PDU, as a single entity of the network bus, gateways, and COM stacks. These grouped signals have a cyclic redundancy check (CRC) calculated for them, some form of counter (alive, frame, or other depending on the scheme chosen), and a data ID, although other methods can be used. These protection methods are identified as schemas by AUTOSAR, which has included common mechanisms used to provide the protections, including the CRC calculations. OEMs and systems integrators can shape their own design rules according to the risks identified in their system design methodology.

The network designer groups signals based on the functional requirements identified in the systems design phase and structures these groups in the network design or re-includes the groups in the case of carry-over from existing projects. Documentation demonstrating that the design fulfills requirements, rules and standards in place supports auditing of the application of E2E protections. These mechanisms are set by the sender and used by the receiver to confirm that the data is fresh, valid, and from the correct sender. The system design must be robust enough to cope with potentially correct data occasionally being rejected, or invalid data being accepted, both infrequently and usually as single occurrences, but over thousands of hours of usage of millions of vehicles, these infrequent events occur.

Cybersecurity

Aligning with functional safety, the ISO/SAE 21434 standard provides principles and processes when designing vehicle systems requiring cyber security. To satisfy functional safety, received data is checked for consistency and correctness with what was sent, with a limited check that the signal group is correct. Cyber security includes additional checks to authenticate that the data is from the correct sender, and sometimes includes encryption of the data itself, though both generally are not needed together.

Modern vehicle systems can exchange data such as phone numbers, addresses, payment details and more. These types of data contain personally identifiable information (PII) and needs to be encrypted both during transmission and in storage, and thus encryption keys are also needed to write and read the data.

Data used for control decisions with safety relevance needs to be trustworthy. In some cases, the overall system design may contain sufficient redundancy in the sourcing or sensing of this data that full protection is not needed on every element, and a fusion algorithm may be used to resolve conflicts. It is also possible that this part of the system design is constrained by the sourced system components and network technology available (bandwidth, maximum PDU size, etc). Eliminating or reducing these constraints is a primary driver to higher baud rate networks with larger payloads per frame.

The control data coming from the decision algorithm, which may be instructions on control inputs for steering, acceleration, braking and more, has a direct impact on the vehicle behavior. The system design has to assure that this data is correct, and, thus, authenticating control data at the target motor or actuator is highly desirable. Possible authentication mechanisms include a hashed (#) version of the signal group that enables the receiver to perform an additional keyed check of the data.

It’s common to use multiple protections to mitigate different risks. Redundant copies or paths for the data can help, however, determining which data to trust when a conflict occurs is an important design consideration. In contrast to functional safety, cyber security protections manifest as built-up layers of defense across the platform, its cloud connections and more. Special care must be taken to ensure all appropriate layers are in place for systems determined to be at risk.

Power modes

Traditionally, vehicle networks have been designed to remain all awake to ensure functionality is available when needed. Special attention is paid to designing robust shutdown procedures that occur when the vehicle is in an appropriate state. This method sustains safety-related functions and backup functionality to enable parking brakes or maintain limited powertrain operation in the event of a faulty network. For maximum energy efficiency, it is desirable to shut down what isn’t currently needed or needed on shorter notice than the wake time of the components which are asleep or powered down.

Partial networks allow some networks to be shut down when not needed. Pretended networking is also used occasionally, where some ECUs go into a low-power mode, but continue to be active on the networks. Power modes can, and do, get more complicated. It is very important that needed signals and data can be generated by awake ECUs, using awake sensors, and sent over networks that are awake. Power modes can therefore quickly constrain the routing of signals.

Complexity

Finally, complexity (defined as options and variants) must be considered at a full system level as it is impacted by everything discussed. Most vehicle programs share a common underlying E/E architecture across a range of vehicles of different sizes, body types, for different markets and more. An OEM’s low-specification car uses fewer ECUs overall than its high specification car, based on the respective vehicle features. Some signals are available on all variations, while others may change source due to being calculated or measured differently for different vehicle types. A vehicle speed algorithm, for instance, will consider different wheel slip behavior on two and four–wheel-drive vehicles. The mechanisms covered for functional safety and cyber security also need to consider the relevant vehicle variations.

Summary

This article covers a wide range of challenges and considerations during the network design phase of E/E systems development. Each of these challenges and decisions can have widespread, cross-domain effects that are difficult to predict or even fully understand. Connecting the many disciplines enables designers to understand the downstream impacts of their decisions during development, critical for accelerating the vehicle development process. Networks design considers and implements many elements vital to ensuring correct vehicle functionality and protecting the entire system from incorrect sub-system behavior. It is important to select a solution which consistently and correctly generates the configurations and documentation used in the development and validation of each ECU making up the full system.

Capital Networks from Siemens has been developed to address the specific needs of the design of vehicle networks. Bringing together learnings from its predecessors, used by multiple OEMs across the world, the AUTOSAR flow and framework, plus many years of industry learning, this is one of the automotive industry’s most robust software tools for networks design. Capital Networks is a model-based design solution, offering generative design capabilities, that ensures efficient design of performant networks across the multiple interdependent complexities of modern E/E architectures, used across multiple vehicle platforms. Built-in consistency checks use design rules and models to ensure design correctness, guiding the user to the any areas needing attention. Correct-by-design outputs in AUTOSAR or other formats are generated to configure each ECU, or validate whole networks, including the needed elements for functional safety and cyber security. To learn more, visit: https://www.plm.automation.siemens.com/global/en/resource/capital-networks/93939