{"id":114,"date":"2020-06-20T05:22:00","date_gmt":"2020-06-20T09:22:00","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/ee-systems\/?p=114"},"modified":"2026-03-26T13:39:47","modified_gmt":"2026-03-26T17:39:47","slug":"clearing-the-road-ahead-for-automotive-e-e-innovation","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/ee-systems\/2020\/06\/20\/clearing-the-road-ahead-for-automotive-e-e-innovation\/","title":{"rendered":"Clearing the road ahead for automotive E\/E innovation"},"content":{"rendered":"\n

The road forward for automotive\nOEMs and their suppliers remains lengthy and confusing. While full vehicle\nautonomy is a popular topic, highly impactful technologies will reach maturity\nlong before true self-driving is achieved. These new technologies will further\nincrease the demands for capability and reliability from the E\/E architecture. <\/p>\n\n\n\n

The E\/E architecture is a\nconvergence of domains: electronics hardware, network communications, software\napplications, and electrical wiring systems all combine to make up the vehicle\narchitecture. Currently, these domains operate with only limited knowledge of\nthe activities, constraints, and goals of the other domains. Likewise,\nfunctional domains, such as powertrain, chassis, infotainment, and others, are\noften only loosely connected. This can cause significant problems where these\ndomains interact. <\/p>\n\n\n\n

For example, several teams within\nan OEM may be developing software applications for the core ADAS ECU in the\nvehicle. These teams are organized by feature and work independently. There\nwill be separate teams for the lane departure, active cruise control, and other\napplications. In order to ensure flexibility for future updates, a constraint\ncaps the processor utilization for this ECU at around 75%. When each of the\nteams loads their software onto the ECU, they exceed the utilization cap and\neven the capabilities of the processor. This happened because each of the teams\ndeveloped their implementations independently and had no ability to understand\nthe totality of the load on the ECU until it was beyond a critical point in the\ndevelopment process.<\/p>\n\n\n\n

Automotive manufacturers and\nsuppliers will need to adopt a new, integrated design methodology to handle the\ninteractions between these domains in an environment that is rapidly becoming\nmore complicated. Major automakers are undertaking extensive reorganizations to\nbetter align with these needs. <\/p>\n\n\n\n

A New E\/E Methodology<\/h4>\n\n\n\n

Establishing an integrated and\nconnected product design, engineering, and manufacturing flow is difficult.\nThese domains have traditionally operated within silos, completing their tasks\nwith minimal external interaction. In addition, the engineering tools in use at\nmany OEMs and suppliers are not built to integrate among domains or share data in\na controlled, streamlined fashion. Due to these organizational challenges,\nengineering decisions in each domain are not being made from a unified set of\ndesign data. As a result, errors and incompatibilities are common as\ncross-domain work is brought together to create the final E\/E system design.\nSome of these may be relatively simple to resolve, but others, such as the ECU\nexample above, result in major re-work efforts, costing time and money.<\/p>\n\n\n\n

Many companies have attempted to\nfacilitate collaboration among engineering domains to prevent these errors.\nMeanwhile, they continue to rely on legacy engineering tools that do not\nsupport such collaborative efforts. In particular, these solutions lack a\nunified data management system, causing engineers to spend time sorting through\nfile systems and manually exchanging information. Design changes, especially\nthose at the system level, are particularly arduous as engineers must propagate\nthese changes to all affected domains and design variants manually.<\/p>\n\n\n\n

The adoption of digitalized E\/E systems engineering solutions that support the full development flow, from definition through manufacturing and maintenance, will prove critical as automotive manufacturers and suppliers meet the demands of today’s automotive industry while developing the technologies of tomorrow (figure 1). These solutions enable automotive companies to construct comprehensive digital twins of vehicles and subsystems for virtual design and verification. Advanced solutions support data coherency and cross-domain integration throughout the flow while leveraging advanced automation capabilities to improve engineering efficiency. The engineering environment provided by these solutions enables each domain to operate within a system-level context during domain-specific engineering. With a system-level context, engineers can evaluate design alternatives, root out issues, and achieve higher quality designs in less time.<\/p>\n\n\n\n

\"Capital
Figure 1: Automotive manufacturers will need a digitalized E\/E systems engineering solution that supports the entire flow, from definition through production and maintenance. <\/figcaption><\/figure>\n\n\n\n

For example, as engineers define the E\/E architecture for a new vehicle, they can leverage software models and early ECU abstractions to enrich the vehicle architecture, enabling optimization from the beginning. The robust data model of E\/E systems development solutions, such as Capital (part of the Xcelerator portfolio), ensures that each domain has access to the most up-to-date information from the other domains. This helps engineers identify and resolve issues virtually, before they become too costly.<\/p>\n\n\n\n

In another example, tight\nintegrations between the E\/E systems and mechanical engineering solutions allow\nthe electrical system and wiring harness to be designed with explicit knowledge\nof the wet, hot, and noisy areas of the mechanical design. Doing so allows the\nECAD designer to account for the impact on the electrical performance of these\nareas when designing the electrical system. On the mechanical side, space\nreservations can be made and the severity of bends in the harness can be\nadjusted to account for the wiring bundles that must route through the\nmechanical structures. With access to this contextual information from the\nother domain, both electrical and mechanical engineers are able to reconcile\nincompatibilities between the ECAD and MCAD designs quickly. This integration\nnot only facilitates the development of a product that meets electrical and\nmechanical requirements, but also accounts for design for manufacturing (DFM)\nconsiderations from the onset of the process.<\/p>\n\n\n\n

The benefits of digital transformation even extend into the service and maintenance of vehicles. E\/E systems development software can automatically create service manuals and signage. These solutions reuse data directly from upstream engineering processes. Engineers no longer need to take data from a spreadsheet and manually redraw wiring diagrams. All the necessary data can be imported and automatically laid out into accurate wiring diagrams. In addition, the generated service manuals are smart, interactive documents that guide technicians through diagnosis and repair processes, and allow technicians to customize schematic views as necessary by VIN.<\/p>\n\n\n\n

Change management<\/h4>\n\n\n\n

Change management is an ever-present challenge in automotive E\/E systems development. Changes can be introduced in any functional domain and during any stage of development (figure 2). As changes are identified, they must be communicated to each affected domain, evaluated, integrated, and verified to ensure that vehicle functionality has not been disrupted. The effects of these changes, especially those made at the system level, can be broad. Each change can affect multiple systems, both software and physical, and the unforeseen effects can be very difficult to predict.<\/p>\n\n\n\n

\"\"
Figure 2: Change is a constant in vehicle program development. New requirements or changes can come from each process, functional domain, or abstraction level during vehicle development. <\/figcaption><\/figure>\n\n\n\n

Migrating an ECU to a new location or\nnetwork in the architecture may affect performance elsewhere in the vehicle.\nThis change in behavior may cascade, causing any number of sub-systems or\nfunctions to fail. Such a change can even completely invalidate the technical\nimplementation of the architecture, driving widespread re-design. For example,\nthe type and location of the ECU that governs human-machine interfaces, such as\na touchscreen infotainment system, can have dramatic effects on the\nresponsiveness of the user interface. Failing to resolve issues with\nunresponsive or slow user interfaces can lead to customer complaints and\nnegative brand evaluations from a perceived inconsistency or unreliability of\nvehicle functions. <\/p>\n\n\n\n

Today\u2019s solutions facilitate all aspects of change management from definition, to implementation and review, to effective communication. Detailed change orders can be created within the E\/E systems engineering solution, and quickly propagated to all affected designs. Integrated change policies automate control over the flow of changes by determining data ownership and permissions to make changes. The impact of the changes can also be assessed for all buildable configurations of a vehicle, then stored, rejected, or approved and re-applied to any revision in any order. Such capabilities can help companies turn the burden of change management into a competitive advantage by accomplishing it faster and more accurately than the competition.<\/p>\n\n\n\n

Read more in our paper: The criticality of the automotive E\/E architecture <\/a> and previous blog post<\/a><\/p>\n\n\n\n

You also might be interested in:<\/p>\n\n\n\n