Looming large for those developing the next-generation autonomous vehicles is a challenge of identifying requirements for their new E/E architecture.

The increasing complexity of today’s road vehicles is a well-proven trend. Connected vehicle features are increasing in all categories and segments, while more powerful smart features are becoming available through the integration of underlying functions.

All of these advanced capabilities rely on electrical wiring and electronic components to function. Cost and time pressures on automotive original equipment manufacturers (OEMs) and systems integrators, however, have only increased. These companies need modern solutions to keep up with the pressures of increasing vehicle complexity and shortening timelines for product development.

A key challenge in this process is the decomposition of electrical/electronic (E/E) requirements from a high-level vehicle model. Multi-domain modeling at the top-level covers mechanical, E/E, software, thermal and other domains that make up the final vehicle. Engineers can extract E/E aspects from this model to drive the construction of an E/E architecture and further processes downstream. Throughout this process, the various engineers concerned with the definition, design, and delivery of modern E/E architectures must balance many interdependent requirements. This article covers interdependent requirements and design technologies to assist engineers at each stage, including:

• Topology


• Functional safety


• Cybersecurity


• Power modes


• Processor, network, and gateway loadings


• Component and software reuse

Topology

The majority of engineering tasks at this stage usually focus on optimizations to the topology and functional allocations. Examples include:

• Moving a secondary network connection of an ECU between domain-focused networks and a private link between a subset of ECUs


• Upgrading an ECU to support a higher baud rate network on one or more connections


• Moving to a new domain to support advanced or additional functions

The last few years have seen a relatively easy transition from central gateway or multi-bus architectures to functional domain controller architectures that support the consolidation of functions into fewer ECUs (figure 1). ECUs are usually carried over within a functional domain, with modest updates to adapt them to the new vehicle. The next phase is to reorganize the ECUs as more generic computing units, where units hosting the most functions and requiring the most power are centralized. Zonal ECUs bring the remaining functions together according to the physical layout of the vehicle. Implementing these zonal ECUs generally requires a bigger change to the software and supplier interactions.

Functional safety

Functional safety requirements create multiple considerations during E/E architecture definition. Specific considerations vary by function, but the industry has now adopted ISO 26262 as the standard for functional safety. ISO 26262 categorizes functions as quality management (QM) or automotive safety integrity levels (ASIL), from A up to D. ASIL functions have some potential to undermine the functional safety of a vehicle in the event of an unmitigated failure. ASIL A functions present the least risk and ASIL D the most significant.

Functional safety of an overall system can be achieved in several ways. Hardware and software platforms, which host vehicle functions, are developed to a specific integrity level to support functional safety. Another method is to add redundant parts to the system. Instead of enhancing one sensor system to support an ASIL D function, it may be preferable to use two ASIL B(D) sensors to deliver sensor data to an ASIL D function. There is also an increasing need to consider fail-functional behaviors, especially in higher-level ADAS functions (3+) that result in broader system-level considerations, such as more layers of redundancy around power networks, communications, processing, sensors, and more. These additional layers of redundancy might include technological redundancy. The various sensor types used to enable advanced ADAS functions offer an illustrative example (figure 2).

Cybersecurity

While functional safety is concerned with systems reliability, cybersecurity must account for malicious attacks against vehicle systems. Modern vehicles have multiple potential vulnerabilities, known as attack surfaces. Integrated Wi-Fi, cellular, Bluetooth, on-board diagnostics (OBD), USB, and other connection points all provide potential routes into the vehicle communication systems. Even network bus circuits have been accessed as entry points, usually for theft purposes. Attack surfaces can be considered in architecting anti-theft systems. Some systems can be made physically inaccessible to malfeasants, while others may use extra software authentication checks to prevent unauthorized access. Cybersecurity and anti-theft systems choices cascade requirements out to the 3D electrical system design via the logical systems containing security functions.

Cybersecurity is achieved with a layered approach, with mechanisms repeated at key points in the architecture. ECUs hosting specific functions may be required to contain integrated hardware security modules (HSM). While HSMs may be emulated in software, which is demanding of processing resources, hardware-based security measures are increasingly common. Data classified as cybersecurity-related can also be designed with specific protections to add further layers to the overall cybersecurity system.

Power Modes

Today’s vehicles often have multiple power modes governing what is powered and/or awake. A vehicle with a traditional key usually has four positions on the ignition switch, translating to 4-6 power modes, from off and locked, to cranking (Table 1).

Functions must be hosted on ECUs that are powered up when the function is required. Thus, functions hosted on an ECU can influence when the ECU needs to be powered or awake, and thus the durability requirements of the ECU. If a function is needed during electric vehicle charging, the ECU that hosts the charging-related function must remain reliable up to 10x longer than that of an ECU only used when the vehicle is in motion. This extends further when service and diagnostic functions are considered, such as vehicle software updates. 

Processor, Network, and Gateway Loads

Another important architectural consideration is the relative loadings on each ECU processor, network or network branch, and the gateways between networks. As functions are allocated to specific ECUs, their associated signals place additional load on the networks connected to the ECU. If direct connections do not exist between the signals’ respective sources and destinations, then a gateway is needed for the connection. Each new gateway increases the load and frequency of signals sent to deliver a given timing. In a functionally-oriented domain architecture, the routing of status and mode information signals may need to travel across the network backbone, resulting in two gateways. Cross-linking between networks is undesirable since cyber-security functions make it difficult to defend as more routes around the architecture become available for malicious actors to traverse. 

A design tool that enables studies of multiple allocations to predict the consequences of each allocation can save substantial time and support correct architectures the first time. For functional allocations to ECUs, it’s critical to consider the specific type of processing for each ECU (Table 2). The main processing ECUs in each domain have differing characteristics. When functions are added to an architecture during an update, they must be split and assigned appropriately to ECUs suitable for running each type of function.

Hard real-time processes are extremely time-sensitive and must execute within a small time window, with a regular processing period. This process may be scheduled at a high frequency and triggered by, for example, engine crank angle, or motor rotor position. Examples range from the control of fuel injection on direct-injection petrol and diesel engines to the control of active suspension components, anti-roll and anti-sway bars, and dampers.

Typical body functions, such as lowering a window, can respond in tens of milliseconds for a satisfactory user experience. However, certain functions can introduce an ASIL and hard real-time requirement into these body functions. With an anti-trap function (automatic window closing if detecting a child’s arm), the feature operation of the windows includes safety-related functions. Consideration is necessary for hosting the automatic window feature in parts of the architecture with sufficient integrity and timing capability. In general, body functions are highly distributed, using sensors and actuators placed around the cabin to build up sophisticated comfort and convenience features. 

Reuse

Reusability of vehicle features, functions, and systems is now essential. Electrical and electronic architecture optimization and effective systems design are critical to maximizing reusability, reducing the number of vehicle variants, and improving the ability to deliver the right vehicle, on time.

When a new or updated vehicle line is being developed, there are constraints around the reuse of vehicle content. Some constraints are firm, while others need to be evaluated relative to associated costs. Traditionally, ECUs from Tier 1 suppliers have a limited scope to add functions unless the supplier is contracted to develop such functions. OEMs are taking more responsibility in developing ECUs, software models, and even full software. Today, this extends to hardware for strategic modules and designing the silicon.

Once the architect determines where functions can be allocated, the ECU type, installed software, and its source are considerations. Ideally, these considerations are established when the OEM decides which ECUs are strategically important for functional allocations over the life of the ECU and architecture.

Conclusion

The challenges facing OEMs developing E/E systems are numerous, varied, and increasing in complexity. E/E system architects have countless considerations when developing, updating, and optimizing vehicle architectures. Therefore, it is necessary to use advanced tools such as Capital Systems Architect from Siemens Digital Industries Software to plan and check the architecture against a set of rules and guidelines defined by the engineers. With extensible rules, system architects can automate assignments and allocations based on the rules defined. Insight metrics enable trade-studies between topological changes, functional allocations, and signal assignments for early optimizations of the E/E architecture before detailed design work begins.

About the Author

Brendan Morris is a senior technical marketing manager for the Integrated Electrical Systems group, Siemens Digital Industries Software. Brendan has worked with automotive Tier 1 suppliers, several vehicle OEMs, and led projects with Jaguar Land Rover, McLaren Automotive, and Rivian. Morris holds an M.Eng degree in Automotive Engineering from Loughborough University.

The post appeared first on .