《西门子(Siemens):不断变化的汽车行业格局(英文版)(28页).pdf》由会员分享,可在线阅读,更多相关《西门子(Siemens):不断变化的汽车行业格局(英文版)(28页).pdf(28页珍藏版)》请在三个皮匠报告上搜索。
1、This eBook describes the challenges that go into the development of electrical and electronic(E/E)architectures of todays highly connected consumer and off-road vehicles and how to simplify the design process.To support the next generation of automotive products,manufacturers need modern solutions i
2、nvolving advanced electrical,network and software engineering to help keep up with the complexity and shortening product development timelines.The changing automotive landscapeFacing significant network architecture and design challengesDeploying safe and secure automotive-grade embedded software wi
3、th V&V020919WHATS INSIDEand more DIGITAL EBOOK AN EE WORLD RESOURCEThe changing automotive industry landscapeSPONSORED BYSPONSORED BY2Collaborating across functional domains with an increase of E/E architecture,networks and softwareAs the automotive industry evolves,the pressure to develop more adva
4、nced E/E architectures for todays sophisticated,highly connected,on and off-road vehicles is growing.Connected vehicle features are seeing increased adoption in all categories and segments,while powerful smart features are becoming available through the integration of underlying functions.These adva
5、nced capabilities rely on electrical wiring and electronic components to function,driving an increase in the number and sophistication of these components.At the same time,automotive network design and software development is becoming more challenging.Network designers and software engineers must sy
6、nthesize dozens of new considerations to support the next generation of automotive products,including vehicle electrification,electronic complexity,government regulations,new business models and automated driving.Furthermore,cost and time pressures on automotive original equipment manufacturers(OEMs
7、)and systems integrators are unrelenting.In fact,the pressure on OEMs and integrators to have the right products at the right time has only increased.These companies need modern solutions to keep up with the combined pressures of vehicle complexity and shorter timelines for product development.Other
8、wise,they run the risk of falling behind in the push for advanced and attractive vehicles.Assisting engineers with interdependent requirements and technologiesGrowing E/E content A key challenge in modern automotive architectural design is the decomposition of E/E requirements from a high-level mult
9、i-domain vehicle model.Multi-domain modelling at the top level will cover 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 th
10、is process,the various engineers concerned with definition,design and delivery of modern E/E architectures must balance many interdependent requirements.These requirements include:Topology Functional safety(FuSa)Cyber security Power modes Processor,network and gateway loadings Component and software
11、 re-useTopology Modern vehicles are rarely developed from a clean sheet.Even new market entrants that lack legacy architectures to re-use,often purchase electronic control units(ECUs)for less strategic locations in the architecture.Most programs will carry forward at least some of the elements or ph
12、ilosophy of earlier architectures(figure 1).The move from architectures with a central gateway toward those with functional domains connected by a backbone network to a world of centralized compute with zonal outstations,comes in stages.The topology often comes with a baseline set of assumptions,whi
13、ch leaves engineers to manage the optimization details(figure 2).Examples could include:Figure 1.An illustration of the main types of E/E architectural philosophies.Multi-bus gateway architectures are giving way to domain controller architectures and,eventually,zonal architec-tures with centralized
14、computingThe changing automotive industry landscapeMulti-bus gateway architectureFunctional domain controller architectureZonal architecture with centralized computeGatewayFunctional domain controllerCentralized generic computeZonal controllerLINCAN FDCANAutomotive ethernet/HDBase TMOSTA2BLVDSAutomo
15、tive SerDes/GMSLECUSensor/actuatorSPONSORED BY3The changing automotive industry landscapeCONTINUED Moving an ECU secondary network connection between domain-focused networks and a private link between a sub-set of ECUs Upgrading an ECU to support a higher baud rate network on one or more connections
16、 Moving to a new domain to support advanced or additional functionsThe transition from a central gateway to a functional domain-oriented architecture is typically easy at a topology and connectivity level.Most ECUs are still connected to a functional sub-network in either scenario.However,to receive
17、 the benefits of a domain-oriented architecture,functions need to be hosted in the domain controllers.This reduces the need to constantly add more processing resources to most of the ECUs.Additional benefits are received when this enables consolidation of ECUs.Rather than adding more ECUs,domain con
18、trollers are usually an upgrade or new generation of one of the higher power ECUs in each domain.The result is fewer individual ECUs are needed over time with such consolidation.Functional Safety FuSa requirements create multiple considerations during E/E architecture definition.Specific considerati
19、ons will vary by function,but most of the industry has adopted the International Organization for Standardization(ISO)26262 as the standard for FuSa(figure 3).ISO 26262 has two overarching functional categories.Quality management(QM)functions do not need to consider FuSa requirements and only need t
20、o be developed to normal quality standards.Other functions are assigned an automotive safety integrity level(ASIL),from A to D.ASIL functions are those that have some potential to undermine the FuSa can be achieved in several ways.For instance,functions in modern vehicles are usually enabled by vari
21、ous components from multiple domains.Some of these must be allocated to hardware or software platforms that are developed to a specific level of integrity to ensure the safety of the function.Another method is to add redundant parts to the system.Instead of trying to enhance one sensor system to sup
22、port an ASIL D function,it is easier to use two sensors of a lower integrity level since they can still support an ASIL D function(figure 4).However,two sensors may only allow for fail-safe functionality,which only requires that the system remains safe in the event of a failure.To achieve the next l
23、evel of FuSa,called fail-operational and which requires systems to remain functional despite a failure,a third sensor,two higher-integrity sensors,another redundant system or model-based calculation that fuses data from other sources may be necessary.An additional FuSa consideration may be a redunda
24、nt power supply for critical components.Dual batteries,dual power circuits and independent fusing all need to be considered.For higher levels of integrity,technological redundancy becomes more important.This entails the use of multiple technological approaches to achieve the same function.A FuSa of
25、a vehicle in the event of an unmitigated failure.ASIL A is the most minor level and ASIL D is the most significant.E/E Architecture topology decisionsFigure 2:Topology optimization may include moving networks connec-tions,upgrading ECUs and more.Domain controller architectureSensor/ActuatorECUOption
26、al fitmentFunctional Domain ControllerFuSa capableFigure 3:Example architecture that incorporates ECU constraints when allocating functions.Figure 4:The combination of two ASIL B(D)sensors can support ASIL D functions.SPONSORED BY4prominent example is the array of sensor types used to enable ADAS an
27、d self-driving features in modern vehicles.Most use a combination of radar,camera,LIDAR,sonar and other sensor types,with multiple versions and devices of each type installed on the vehicle(figure 5).Each of these sensor types has different strengths and weaknesses,such as range,weather tolerance,ob
28、ject detection and more.The complete system can build up a dependable and accurate understanding of its surroundings by fusing data from each sensor type.From these considerations,some rules and guidelines for E/E architects can be derived that cover both the development of the base architecture and
29、 the allocation of functions to that architecture(including how functions are partitioned).One guideline could be to decompose FuSa requirements where possible.In a common use case,data gathered from sensors with redundancy,either from a duplicate or backup sensor,can be processed on an ECU of a low
30、er integrity level than needed by the whole system if the redundant sensor and data processing are separated.The system can achieve its required safety integrity through the combination of sub-systems and elements which may not all individually delivery the full system goals.The result is the archit
31、ect can allocate input,processing,decision and action functions to appropriate ECUs based on their attributes and redundancies in the system.These FuSa requirements constrain the architects options for functional allocation.Yet,there are further considerations.Design tools need to include attributes
32、 for every function,signal,ECU and all other element types,with extensible properties to support architectural studies.The properties list can be expanded per the needs of the OEM and used for trade studies using instant metrics and rules to ensure designs meet the defined goals and standards.Cyber
33、security FuSa and cyber security share some surface similarities:both concern the correct functionality of vehicle systems.But while FuSa is mostly concerned with the reliability of systems and the consequences of failures,cyber security must account for malicious attacks against vehicle systems.As
34、a result,cyber security has distinct requirements aimed at defending against such attacks.Modern vehicles have multiple potential vulnerabilities,known as attack surfaces.CYBERSECURITYWant to learn more about multi-layered approaches to connected vehicle security and how to protect vehicle entry poi
35、nts as well as in-vehicle networks?This white paper covers several security strategies including embedded firewalls,authentication,secure communications,encryption and digital certificates.White Paper:Modern automotive cybersecurity through secure communication,strong authentication and flexible fir
36、ewallCLICK HERE TO VIEW THE WHITE PAPERLong-range radarLIDARCameraShort-/medium-range radarUltrasoundFigure 5:Overlaying redundant sensors enables ADAS and self-driving systems to achieve higher levels of functional safety integrity.The changing automotive industry landscapeCONTINUEDSPONSORED BY5Int
37、egrated Wi-Fi,cellular,Bluetooth,on-board diagnostics(OBD),universal serial bus(USB)and other connection points all provide potential routes to the vehicle communication systems.Even network bus circuits have been accessed as entry points,usually for theft purposes.These attack surfaces can be consi
38、dered in architecting of the anti-theft systems.Some systems can be made physically inaccessible to malfeasants,while others may use extra software authentication checks to prevent unauthorized access.However,it is strongly desirable to have both.The choices made on cyber security and anti-theft sys
39、tems cascade requirements out to the 3D electrical system design via the logical systems containing security functions.Design solutions that can link the 3D and electrical worlds with rich data and can differentiate the types of signals and their physical manifestations,are vitally useful throughout
40、 the concept stages to verify designs.Cyber security is achieved with a layered approach.Some mechanisms are repeated at key points in the architecture and different mixtures of mechanisms are applied at each level in the system.The placement of firewalls,or connections of interfaces on ECUs that fe
41、ature firewalls,need to be considered with respect to the various entry routes that an attack can use to gain access to the vehicle.ECUs hosting specific functions may also be required to contain integrated hardware security modules(HSM).It is possible to emulate an HSM in software by careful select
42、ion of the integrated circuit(IC)at the heart of the ECU.This emulation is very demanding of processing resources,so hardware-based security measures are gaining popularity.Data classified as cyber security related can also be designed with specific protections to add extra layers to the cyber secur
43、ity system.Like FuSa,software tools that use attributes and properties enable designs to include security functions and requirements.Design rule checks(DRC)enable engineers to check the design against defined rules and diagram styling enables easy visual understanding and auditing of those details.P
44、ower modes Modern road vehicles often have multiple power modes,some visible to the user,others relatively hidden.These reflect the functions active in the vehicle and govern what is powered and/or Table 1:A summary of typical basic power modes.Table 2:An expanded summary typical for vehicles with e
45、lectrified powertrains.11.Table 2 shows a simple example.In practice,there is more to resolve,such as:Software updates that require selective update of target networks and ECUs.Software updates of charging ECUs require interlock and handover logic.*Regional differences in the nature of interactions
46、between charging and powertrain activation.*Some regions require blocking of powertrain activation while on charge.Others call for charging to be suspended in the event of powertrain activation.Also,further refinement is needed for inductive charging where no disconnect is needed.The changing automo
47、tive industry landscapeCONTINUEDSPONSORED BY6awake.A vehicle with a traditional key will usually have four positions on the ignition switch,translating to four to six power modes,from off,locked,to cranking(table 1).Many OEMs use terms such as KL15(also known as Contact 15)and KL30 associated with t
48、ables 1 and 2,at the right and below.Derived from the German Institute for Standardization(DIN)72552,some OEMs use many more power modes while others have their own specific terminology.Some use several state tables that merge.For example,a basic power mode with a second state machine to handle the
49、activation and deactivation of the powertrain.This arrangement is increasingly likely in an electric vehicle,as the above basic table does not include electric powertrain-specific power modes,such as a charging mode.In modern vehicles,functions need to be hosted on ECUs that are powered up when the
50、function is needed.As a result,the functions hosted on an ECU can influence when the ECU needs to be powered.This second point is increasingly important:if a function is needed during charging of an electric vehicle,the ECU that hosts the charging-related function will need to remain reliable over a
51、 life up to 10 times longer than an ECU only used when the vehicle is in motion.This extends further when service and diagnostic functions are considered,such as software updates to the vehicle.Software over the air(SOTA)updates will be increasingly common,rather than the service center update that
52、has become practically universal in recent years.Over the air updates require another partial awake mode.When the vehicle is powered off or asleep,waking a domain or network at a time will be enough to perform the update.In other cases,such as vehicles that are not plugged in to charge,downloading t
53、he software in the background when the vehicle has signal is a more cautious approach.At the start or end of a drive-cycle,the vehicle can request user permission to perform the update.The architect needs to consider these low-power mode states and which module will host downloaded updates prior to
54、deployment.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 will place additional load on t
55、he networks connected to the ECU.If direct connections do not exist between the signals respective sources and destinations,then a gateway is needed to make the connection.Each new gateway increases the gateway load and the frequency signals must be sent to deliver a given timing.Further,in a functi
56、onally oriented domain architecture,it is likely that the routing of status and mode information signals may need to travel across the network back-bone,potentially resulting in two gateways.Cross-linking between networks is increasingly undesirable as it makes functions critical to cyber-security m
57、uch harder to defend as more routes around the architecture become available for malicious actors to traverse.Consequently,the E/E architect benefits from an understanding of each of the functions planned for the architecture when optimizing the networks and domains that each ECU is connected to.Tab
58、le 3:Examples of typical ECU processing types per functional domain.The changing automotive industry landscapeCONTINUEDSPONSORED BY7As mentioned earlier,a design tool that enables trade studies of multiple allocations and can predict the consequences of each allocation can save substantial time and
59、support the delivery of correct architectures the first time.When considering functional allocations to ECUs,it is important to consider the specific type of processing in each ECU.The main processing ECUs in each domain have differing characteristics(table 3).When functions are added to an architec
60、ture during an update,they need to be split and assigned appropriately to ECUs suitable for running each type of function.Image processing has very different needs for decision making and control outputs.Image and radar processing are soft real-time processes,where the series of images are processed
61、 into objects,cars,cyclists,road signs,road markings,etc.Trajectories will also be processed where relevant.Soft real-time processes have a deadline by which time the data must be processed to enable accurate control decisions.The actual processing time has variation,thus high-power compute results
62、in a more consistent delivery.Control and output decisions,on the other hand,are often hard real-time processes,requiring much less processing power.Hard real-time processes are extremely time-sensitive and must be executed in a small-time window in a regular processing period.This kind of process m
63、ay be scheduled at a high frequency,but could also be triggered by an engine crank angle,motor rotor position,etc.Examples range from the control of fuel injection on direct injection petrol and diesel engines,to the control of active suspension components,anti-roll(anti-sway)bars,dampers and more.T
64、ypical body functions,such as lowering a window,can respond in milliseconds and provide a satisfactory user experience(UX).However,certain functions can introduce an ASIL and hard real-time requirement to these body functions.For example,an anti-trap function on an automatic window close feature,use
65、s a closed-loop control with sensor feedback to stop and reverse the motion of the automatic window in the event of a detected blockage,such as an arm or finger.With the anti-trap function,the feature operation of the windows is considered to include safety related functions.Therefore,consideration
66、must be given to the appropriate hosting of the automatic or one-touch 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 an
67、d convenience features(figure 6).Input/output(I/O)connectivity ECU/sensor/actuator New custom ECUs are sometimes,cost permitting,able to be specified exactly as needed.More commonly,new ECUs are derived from a platform design,limiting the capabilities of the ECU and both the type and total number of
68、 connections to the vehicle networks and other inputs or outputs.Conversely,carry-over and purchased ECUs bring in constraints that define how parts of the architecture can work.ECUs normally have a fixed count of I/O once in production.In development,they are constrained by the selected silicon,ava
69、ilable space on the PCB and by the desired connectors.During development there may also be scope to convert certain pins from inputs to outputs,analog to digital or to data buses.Opportunities for these conversions must be frozen at some stage.After this,connections can only be made to the I/O the E
70、CU already has.It is often possible to process a sensor value in the ECU the sensor is connected to and monitor for hardware faults and other errors.The decision function(s)utilizing the sensor data may be elsewhere on the vehicle due to other requirements.Figure 6.The changing automotive industry l
71、andscapeCONTINUEDSPONSORED BY8Re-use It is not practical to develop every vehicle from a clean sheet.Re-usability of vehicle features,functions and systems,which was once desirable,is now essential.E/E architecture optimization and effective systems design are critical to maximizing re-usability,red
72、ucing the number of vehicle variants and improving companies ability to deliver the right vehicle on time.When a new or updated vehicle line is being developed,there are typically constraints established around the re-use of vehicle content.Some of these constraints are firm,while others need to be
73、evaluated in consideration of the relative costs associated.Traditionally,ECUs sourced from tier 1 suppliers have limited scope to add functions unless the supplier is contracted to develop such functions.OEMs are taking more responsibility in developing some ECUs,software models and sometimes full
74、software.Today,this can even extend to the hardware for strategic modules and,in selected cases,as far as designing the silicon.When the architect considers where functions can be allocated,the type of ECU,installed software and its source are a consideration.It is also important to consider if ther
75、e are plans for the ECU to have upgrades or enhancements over its lifetime,to hardware and/or software functions.Ideally,these considerations are accounted for when the OEM is deciding which ECUs are strategically important.This will help provide the scope for functional allocations over the life of
76、 the ECU and architecture.ConclusionThe challenges facing OEMs developing E/E systems are numerous,varied and only increasing in complexity.These challenges are particularly acute at the stage where E/E architectures are being defined and evaluated.There are many considerations that E/E system archi
77、tects must include when developing,updating and optimizing vehicle architectures.These can typically be characterized as attributes or properties of the function,ECU,signal,port and so on.Therefore,it becomes necessary to use advanced tools such as Capital Systems Architect to plan and check the arc
78、hitecture against a set of rules and guidelines defined by the engineers.Capital is part of the Xcelerator portfolio,the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software.Furthermore,with extensible rules,it is desirable to automate assignments
79、and allocations,according to the rules defined.Insight metrics enable trade-studies between topological changes,functional allocations,signal assignments and more,supporting early optimizations of the E/E architecture before detailed design work begins.Taking advantage of innovative tools enables en
80、gineers to verify architectural decisions early.This is increasingly critical as automotive competition becomes more intense and E/E architectures become more important in delivering products that delight consumers.AUTOSARWhy is AUTOSAR the leading solution for automotive software platforms?How can
81、development teams benefit from a comprehensive AUTOSAR solution?Watch this webinar to find out,and also be introduced to an overview of the features and characteristics of VSTAR support including functional safety,cybersecurity,and advanced E/E architectures.Webinar:Evolution of AUTOSAR in automotiv
82、eCLICK HERE TO VIEW THE WEBINARThe changing automotive industry landscapeCONTINUEDSPONSORED BY9Facing significant network architecture and design challenges Technological contextThe E/E architectures used in the automotive industry today are highly complex,with many vehicle features delivered by fun
83、ctionality distributed across multiple discrete ECUs.Commonly,the ECUs,sensors and actuators are not all directly connected and much of the data communication takes place across networks,with gateways over several networks.Modern E/E architectures have become more formally organized around functiona
84、l domains,increasingly with domain computers or controllers acting as a centralized compute and absorbing much of the higher-level functions for that domain.The next trend is the increasing use of service-oriented architectures(SOA),enabled by Ethernet networking.This enables principals from the inf
85、ormation technology(IT)domain to be re-used in automotive applications.The main evolution with such an architecture is the move from thinking about discrete signals to services,which often provide multiple related signals.Functions now provide and subscribe to services according to their functional
86、needs.Moving towards an SOA is happening in parallel with changes to the physical architecture.Computing power is increasingly centralized,with domain ECUs being re-organized into a zonal layout.Some OEMs and integrators opt for high computing power in the zonal ECUs that reside near the sensors and
87、 actuators,while others aim to keep them in simple gateways.Furthermore,moving away from functional domains cascades high integrity requirements into more ECUs across the architecture.The forces driving OEMs towards centralized or zonal architectures are broader than only reducing the ECU count in v
88、ehicles.These architectures can streamline the functionality scalability,with processing and memory headroom only needing to be provisioned in the central compute unit.Centralized or zonal architectures can also help reduce harness mass and lower bill-of-material(BoM)costs to the OEM.It is worth not
89、ing that the speed of this transition is variable across organizations,regions and vehicle market sectors.Well-funded OEMs known for selling premium passenger cars are usually seen as the first movers,but there are also regional variations and new entrants that do not conform to the traditional time
90、lines of automotive companies and some advanced vehicles in more specialist market segments.Usually,these design challenges can be considered by the network designer in relative independence.But,each design decision has an impact on the full system.This impact should be considered at the time of des
91、ign,allowing Multi-bus gateway architectureFunctional domain controller architectureZonal architecture with centralized computeGatewayFunctional domain controllerCentralized generic computeZonal controllerLINCAN FDCANAutomotive ethernet/HDBase TMOSTA2BLVDSAutomotive SerDes/GMSLECUSensor/actuatorFigu
92、re 7.Centralized versus zonal architectures.SPONSORED BY10Facing significant network architecture and design challenges CONTINUEDsystem testing later in the process to confirm correct behavior rather than uncover issues that require design iterations.The instrument cluster,central display(s)and head
93、s-up display(HUD)are increasingly part of one integrated system,an extension of the driver information and infotainment systems.However,there is often more information in the instrument cluster with FuSa considerations.Therefore,several partitions are still required on the compute platforms that hos
94、t these functions.These partitions may be separate processors or separate cores.These systems may have discrete LEDs,switches and other peripherals connected to fully meet their requirements.However,traditional automotive vehicle control switchgear is often connected to a body controller or gateway.
95、Besides the media functions that may be hosted in the infotainment portion of this system,there are many other pieces of critical information to convey to the driver,ranging from vehicle speed and faults,through to driving modes,ice warnings,navigation directions,estimated range,etc.Some OEMs refer
96、to the cluster as a combination meter,as it reflects the history of bringing together what was once multiple instrumentation gauges,warning lights and trip computer elements into one system.Modern domain consolidation is in line with these historical examples,which illustrates the pattern of functio
97、nal growth after each consolidation.Every time functions are consolidated,new functions are added in new components or ECUs-from trip computers,clocks,temperature gauges to ice warnings.With the cluster example,it is common for displayed data coming from a specific control ECU or sensor to potential
98、ly need some smoothing or processing in the cluster.Meanwhile,data from a domain controller or mode function,such as a chassis mode for off-road or sport driving,may need to be more heavily processed to resolve a status or adjust the context or highlighting of information to be ready for presentatio
99、n.Network load,gateway loadIn the days of controller area network(CAN)to CAN gateways,the network designer had a choice between gatewaying whole frames of signals or each signal individually,re-packed into a new frame.This provided a simple trade-Figure 9.An example subset of signal flows.SeatDoorIn
100、verterDampersDCDCAnti-rollBatteryAir springsGatewayPropulsionChassisClusterCentral displayRear seat displayAmplifierFigure 8.An example subset of ECUs in a vehicle architecture.Example signalsMotor powerBattery chargeChassis modeSeatDoorDampersDCDCAnti-rollBatteryAir springsClusterCentral displayRea
101、r seat displayAmplifierInverterPropulsionChassisGatewaySPONSORED BY11off between more processing at the gateway or less-efficient use of network bandwidth.That compromise is still made today AUTOSAR provided protocol data units(PDUs)as a design element to support gatewaying between different network
102、 technologies.This streamlines the gatewaying of PDUs,while preserving the option of reading out individual signals and repacking them in a new PDU.This basic compromise is much more complicated in detail.The designer may need to consider how the gateway will trigger sending the gatewayed data it is
103、 forwarding,which influences the overall latency across the system.In practice,this is often constrained by re-using existing ECUs or frame and PDU designs that support an integration with a supplier across multiple vehicle programs.However,some OEMs prefer using an existing library of pre-designed
104、network messages with pre-defined frame packing to support ECU re-use without changes.The use of a standardized protocol,such as the Society of Automotive Engineers(SAE)J1939 for heavy-duty and off-highway vehicles,provides the ability to connect vehicles and equipment of different brands together r
105、eliably.Both approaches reduce the scope for optimization by the designer,but do not reduce the need to consider the performance and behavior of the design.Networks designers follow design defined by the respective OEM that consider many technical details of the system.For example,the prioritization
106、 or scheduling of each network technology must be considered.The Local Interconnect Network(LIN)and FlexRay are time triggered networks with a schedule.Although,FlexRays dynamic segments give some flexibility for event-driven data and variations in payload size.CAN uses an arbitration mechanism base
107、d on the frame ID.This means that in most designed networks there are frame ID ranges reserved for different types of payloads.This includes both functional and network management needed to run most networks and occasional data such as service and diagnostics.Higher priority is often assigned to dat
108、a that would affect vehicle functions with variable jitter.The use of a model-based design tool permits a left-shift of network validation by understanding the behavior of the network and the consequences of design decisions in worst case scenarios.Capital Networks software has inbuilt models allowi
109、ng the worst-case consequences of design decisions to be predicted,confirming the validity of the design.Rules for frame IDs,consistency of frame packing and the correct configuration of gateways can all be checked and confirmed to be correct-by-design.Further generative automation accelerates labor
110、ious task completion,saving time and reducing manual errors.Ethernet and switchesThere is an increasing need to consider more network technologies across the architecture.Ethernet first appeared in the infotainment system or diagnostics over intellectual property(IP)(DoIP)systems.Now,it is frequentl
111、y expanding across domains,forming a backbone between the functional domain controllers.At AUTOSAR AND HYPERVISORDownload this paper to understand an efficient way to reduce the cost of adding a dedicated micro-controller to each platform.This paper describes types of hypervisor available and their
112、characteristics,as well as a practical example involving AUTOSAR.Learn how a hypervisor can be used as a reliable solution for consolidating both infotainment and AUTOSAR applications on the same ECU!White Paper:Using Hypervisor for IVI and AUTOSAR Consolidation on an ECUCLICK HERE TO VIEW THE WHITE
113、 PAPERFacing significant network architecture and design challenges CONTINUEDSPONSORED BY12this point,Ethernet design,including switch configuration,may expand from a topic specific to the network traffic of a single domain to include more general vehicle data(for example,data passing between tradit
114、ional networks and Ethernet,benefitting from full system considerations).Initially,using Ethernet adds another set of network behaviors to consider and a more complex set of standards and protocols.However,these are more scalable than specialized automotive networks,with the same communication softw
115、are used regardless of Ethernet physical layer type.This makes updates easier over time.As Ethernet networks can interoperate at multiple baud rates,it can be used across a large section of the vehicle,reducing the technological complexity.Media Oriented Systems Transport(MOST)is already fading from
116、 use and was never incorporated into AUTOSAR.FlexRay and high-baud-rate CAN have an ever-reducing set of use-cases for which they are the ideal solution.Only time will show if 10Base-T1S or CAN-XL can fully take over for networks where a 10 megabits per second(Mbps)network is utilized.Ethernet netwo
117、rks introduce additional configuration options for the network designer.Protocols,methods and elements of different levels can be used to 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,virtu
118、al local area networks(VLANs)are used to segregate different types of data and enable these data types to be prioritized,limited(in terms of bandwidth utilization)and even disabled.A specific VLAN may be used to implement software updates,which allows regulation of the bandwidth utilized for specifi
119、c functions,depending on the vehicle status or mode.Audio visual bridging(AVB)was initially created to add specific shaping or prioritization of audio and visual data flows on Ethernet networks.This ensured that audio and visual data could Table 4.A quick reference guide to common automotive network
120、 technologies.Table 6.Time Sensitive Networking(TSN)was developed from AVB as an expansion to include necessary elements to support high integrity use cases of automotive.NetworkMax baud rateMax frame payloadAUTOSAR supportPriority/timingSegregationTopologyLIN20 kbps8 BytesYSchedulePhysical networkL
121、inearCAN1 Mbps8 BytesYPriority Physical networkLinear/StarCAN-FD8 Mbps64 BytesYPriority Physical networkLinear/StarCAN-XL10 Mbps2048 BytesIn developmentPriority Physical networkLinear/StarFlexRay10 Mbps254 BytesYSchedulePhysical networkLinear/Star/HybridMOST2525 Mbps64 BytesNSchedulePhysical network
122、Ring10Base-T1S10 Mbps1500 kBYAVB/TSNVLANLinear100Base-T1100 Mbps1500 kBYAVB/TSNVLANSwitched flexible1000Base-T11 Gbps1500 kBYAVB/TSNVLANSwitched flexibleAVBIEEE standardTime SyncgPTP802.1AS-2011ReservationStream reservation protocol802.1QatQuality of serviceCredit based shaper802.1QavTransport proto
123、colAVTP1722Transport protocolRTP over AVB1733Table 5.Audio Visual Bridging(AVB)was originally created for audio/visual media streams.TSNIEEE standard(s)Redundant Time SyncgPTP802.1AS-2020ReservationStream reservation enhancement802.1QccReservationPath control and reservation802.1QcaQuality of servic
124、eTime aware shaper802.1QbvQuality of serviceFrame preemption802.3br and 802.1QbuQuality of serviceCyclic queue forwarding802.1QchQuality of serviceAsynchronous shaping802.1QcrRedundancyFrame replication and elimination802.1CBTransport protocolAVTP1722-2016Facing significant network architecture and
125、design challenges CONTINUEDSPONSORED BY13be sent across the network without distortions due to variable data rates.AVB was adopted by early automotive Ethernet users,usually in conjunction with scalable service-oriented middleware over IP(SOME/IP)and service discovery(SD),as a method to enable SOA c
126、ommunication.Time sensitive networking(TSN)is a development of AVB specifically for functions and use-cases that have high integrity requirements,such as automotive.TSN extends some of the elements of AVB,while also adding others that were not available before.AUTOSAR has directly included or suppor
127、ted the above technologies and standards as needed.This has avoided the need to reinvent technology that was originally developed for specific purposes.Standards and functionality needed by both classic and adaptive versions of AUTOSAR are standardized in the Foundation standard,enabling compatibili
128、ty and consistency.In the instrument cluster example,any information displayed to the driver must be current(an adequate maximum age from the original measurement or calculation),to represent the actual state of the vehicle.Examples include a fuel gauge or battery state of charge reading or trip com
129、puter functions.The charge or fuel level reading should not Figure 10.The Foundation standard of AUTOSAR provides functionality needed in both the Classic and Adaptive platform versions.change quickly and can likely be updated once per second,potentially with some damping.An energy usage reading,suc
130、h as a power gauge,instantaneous fuel consumption or similar graphic will need more frequent updates.These elements of similar data will come from different ECUs one from a battery management ECU or fuel tank sender and the other from an inverter or powertrain control ECU.Although,these are sometime
131、s consolidated.Network design tools are vital to enabling the correct implementation of these protocols and standards,both traditional automotive networks such as CAN,and those utilized in the automotive industry like Ethernet.Model-based design tools support consistent implementations,predicting co
132、nfiguration problems and mismatches across the full architecture.Capital Networks facilitates the consistent design of data signals,and implementation of protocols across full architectures,considering vehicle variants,options,and the different technologies used.Sophisticated design tools can model
133、full E/E architecture behavior,including timing,bandwidth utilization and other performance measures.These models can also consider the characteristics of each technology,and the prioritizations and allocations made for the data types in use.Configuration of VLANs,the assignment of the relevant subs
134、et of ECUs to each,the audio visual bridging(AVB)/time sensitive networking(TSN)priorities and more can all be managed centrally in the system design,ensuring consistent and correct implementations.Figure 11.Apparently similar data may come from different sources.Classic platformAdaptive platformFou
135、ndationExample signalsMotor powerBattery chargeSeatDoorDampersDCDCAnti-rollBatteryAir springsClusterCentral displayRear seat displayAmplifierInverterPropulsionChassisGatewayFacing significant network architecture and design challenges CONTINUEDSPONSORED BY14Functional Safety:A networks perspectiveNe
136、twork designers have been designing with FuSa 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
137、conventional approach with networks is to treat them as quality measures(QM),as a mechanism,which is defined in ISO 26262.Where required elements are added to the design to validate the data is being received regularly and accurately.Increasing system integrity requirements now demand redundant rout
138、ings for some data,but this is often a system-level design consideration and will only be encountered by the network designer as additional design rules.For instance,a design rule may prevent the routing signals A1 and A2 on the same networks from sender to receiver.Data that carries a potential saf
139、ety consequence if incorrect or missing primarily receives end-to-end(E2E)protection.A group of signals are packaged in a common message or PDU and treated as a single entity in terms of the network bus,gateways and COM stacks.These grouped signals have a cyclic redundancy check(CRC)calculated for t
140、hem,some form of counter(alive,frame or other depending on the scheme chosen)and a data ID.Although,other methods can be used to overcheck the identity of the group.These protection methods are identified as schemas by AUTOSAR,which has included common mechanisms used to provide the protections,incl
141、uding the CRC calculations.This allows OEMs and systems integrators to 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 thes
142、e 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
143、used by the receiver to confirm that the data is fresh,valid,and from the correct sender.However,the integrated protections are only designed to defend against errors and faults and not targeted malicious actions.Thus,the system design must be robust enough to cope with correct data occasionally bei
144、ng rejected or invalid data being accepted,both infrequently and usually as single occurrences.With over thousands of hours of usage of millions of vehicles,these infrequent events will occur sporadically.FUNCTIONAL SAFETYCLICK HERE TO VIEW THE WEBINARAutomotive megatrends of electrification,connect
145、ivity,and automation have intensified the necessity for functional safety.Consumer expectations for end-user vehicle functionality have also increased demands on CPU performance.Watch this webinar for practical design examples,including a system-level framework for partitioned communication introduc
146、ed into the AUTOSAR ECU systems.Webinar:Architecting vehicles for functional safety complianceFacing significant network architecture and design challenges CONTINUEDSPONSORED BY15For E2E protection to be meaningful,the sending and receiving ECU need to be designed with appropriate FuSa consideration
147、s.Protecting a signal which may have been sent incorrectly due to software of inappropriate integrity renders the protection meaningless and a waste of bandwidth.Further,the frame headers of most network types contain some protections that will cause the data in the frame to be rejected if a basic f
148、ault is detected.Although,these usually are not considered to be robust enough for application level data checks,and are only suitable for bus level errors.The information presented to the driver is of mixed criticality.Some elements are safety related or legislated,requiring continuous availability
149、 with sufficient accuracy.Other elements of information are presented for the comfort or convenience of the driver.The simultaneous need to present both safety-related and non-safety-related information introduces requirements not just into the processing and presenting of such data,but also the net
150、works design.Sometimes this includes redundant information sources.However,more commonly,the requirements call for E2E signal protection,or even both.Examples may include airbag warnings if the cluster or warning lamp system misses the data from the airbag controller,it will put the warning lamp on
151、assuming there to be a fault.In contrast,some of the data in a trip computer function is for convenience only and can safely not be shown when not available.Likewise,other than damaging the impression of vehicle quality,occasionally erroneous values may be accepted by design.As with general network
152、design,OEMs have design rules and standards instructing the network design engineers which protections to use in which system design scenarios.Capital Networks includes editors that assist with the set up these safety mechanisms.The design model enables consistency checks to guide the designer towar
153、d problems and makes sure the networks are correct-by-design and consistently described in the software configuration outputs for each ECU.Cyber securityThere are similarities in the approaches taken with FuSa and cyber security the base technology is built upon and in terms of network design,signal
154、 protection elements are added.However,due to the need to mitigate malicious attacks,the mechanisms added need to be more sophisticated.These mechanisms may not always meet the needs of the FuSa on their own and OEMs must consider the risk when selecting the mitigations to be used across a system or
155、 platform for potential threats and/or faults.ISO/SAE 21434 is used to set out best practice principals and process when designing vehicle systems in consideration of cyber security.To satisfy FuSa,received data is checked to be consistent and correct with what was sent,with a limited check that the
156、 signal group is correct.Cyber security includes additional checks to authenticate the data is from the correct sender and sometimes(depending on the systems design)includes encryption of the data itself.Although,use of all mechanisms on the same data is infrequent.MCU SHORTAGEMultiple factors colli
157、ded to create a global microcontroller shortage that forced developers to redesign ECUs using alternative Microcontrollers(MCUs)and find alternative solutions for designing and testing their software.This white paper aims to share ways to arrive more easily and effectively at software that is less d
158、ependent on specific hard-to-get MCU hardware.Discover how to reduce the impact of the global microcontroller shortage on your ECU software development.White Paper:Microcontroller ShortageCLICK HERE TO VIEW THE WHITE PAPERFacing significant network architecture and design challenges CONTINUEDSPONSOR
159、ED BY16Introducing new challenges for the network designer,modern vehicle systems can exchange data such as phone numbers,addresses,payment details and more.These types of data are,or contain,personally identifiable information(PII).This data needs to be encrypted both during transmission and in sto
160、rage.Therefore,encryption keys are also needed to write and read the data.Meanwhile,data used to determine 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 prote
161、ction 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 constrai
162、nts 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 vehicle behavior.The system design must assure that th
163、is data is correct and 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.Control data may also include some indic
164、ator for time,or a step counter.Counters used in automotive networks for FuSa are often four or eight bits,while cyber security counters can be extended to 16,32 or more bits to mitigate a replay attack.It is common to use multiple protections,as per FuSa,to mitigate different risks.Redundant copies
165、 or paths for the data can help,however,determining which data to trust when a conflict occurs is an important design consideration.These protections and others have a bigger impact to both the network designer and the architect than FuSa protections.With cyber security,data sizes tend to be much la
166、rger,consuming more bandwidth.The larger frame sizes of higher baud rate networks such as Ethernet,FlexRay,CAN flexible data-rate(FD),or CAN extra load(XL)can support the greater demands of cyber security,as opposed to traditional CAN or LIN networks.An additional firewall before a CAN or LIN networ
167、k,with health monitoring of the sub-systems from the secure ECU,can provide additional protection to vulnerable parts of the system.VLANs can be used to segregate traffic types on Ethernet and IP networks,allowing bandwidth utilization limits to be set.This can help prevent denial-of-service-type at
168、tacks from affecting multiple systems and enables certain traffic types to be turned off in various modes of operation.For example,software updates can be prevented while the vehicle is in motion.Additionally,firewalls are increasingly deployed at entry points to the vehicle,such as the telematics a
169、nd between the entry points and ECUs hosting higher risk functions.A further consideration is that FuSa can usually be considered in relative isolation.In contrast,cyber security protections manifest as built-up layers of defense across the platform,its cloud connections and more.Special care must b
170、e taken to make sure all appropriate layers are in place for systems determined to be at risk.If we consider the cluster example,functions that relay phone or navigation information onto the driver display might contain PII.This data should typically be encrypted so that it is not readable from a da
171、ta log without the correct key.This data,however,usually does not warrant protection from corruption so that duplicate information is displayed to the driver.The encryption of data containing PII may be more important in markets with privacy legislations,such as Europes GDPR protections,but it is a
172、good practice overall.As described previously,the consequences of this are additional design rules and standards that must be followed by the network designer.Capital Networks models the full vehicle E/E architecture and can perform consistency checks across the full system to make sure the design i
173、s consistent and the cyber security protections are complete,enabling correct-by-design outputs.Power modesTraditionally,vehicle networks have been designed to remain awake to ensure functionality is available when needed.Under this approach,special attention is paid to designing robust shutdown pro
174、cedures that occur when the vehicle is in an appropriate state.This method sustains safety-related functions and backup functionality(for Facing significant network architecture and design challenges CONTINUEDSPONSORED BY17example,enabling parking brakes or maintaining limited powertrain operation i
175、n the event of a faulted network).However,for maximum energy efficiency,it is desirable to shut down what is not currently needed and what will not be needed on shorter notice than the wake time of the components that are asleep or powered down.Partial networks allow some networks to be shut down wh
176、en 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 get more complicated.It is very important that needed signals and data can be generated by awake ECUs,using awake sensors and sent over netw
177、orks that are awake.Therefore,power modes can quickly constrain the routing of signals.Returning to the cluster example,the user has an expectation that certain data is visible in given vehicle modes,such as charging a battery electric vehicle.This data might be offered for the convenience of the dr
178、iver,but could also have legal or safety considerations,such as the current charging status,vehicle odometer or parking brake status.If this data is not calculated or stored in the cluster,it needs to be available to be displayed.While this would have been considered in the E/E architecture definiti
179、on,it still creates network routing and signal packing requirements for the network designer.Capital Networks includes editors that assist and automate setup of these power saving modes,with model-based consistency checks that enable correct-by-design setup of mechanisms,which can be very complicate
180、d to implement.ComplexityFinally,complexity must be considered at a full system level as it is impacted by everything we have discussed.Complexity means options and variants.Most vehicle programs share a common underlying E/E architecture across a range of vehicles of different sizes and body types,
181、for different markets and more.A two-door vehicle may use fewer door modules than a four-door car and a low-specification car will likely use fewer ECUs overall than a high specification car that is driven by features included in the vehicle.All of this is to be considered in the design.Some signals
182、 must be available on all variations,while others may change source due to being calculated or measured differently for different vehicle types.For instance,a vehicle speed algorithm will consider different wheel slip behavior on two and four-wheel-drive vehicles.The mechanisms covered for FuSa and
183、cyber security also need to consider the relevant vehicle variations.Capital Networks allows full consideration of vehicle and ECU variants,using consistency checks to ensure correct-by-design implementations.Implementation files,AUTOSAR configurations or others,can be shared with software teams and
184、 suppliers appropriate to the ECU versions and variants needed.Also,with the increasing size of network architectures and data,generative design will accelerate the completion of laborious tasks,saving time and effort and reducing manual errors.Figure 12.During some modes,such as vehicle charging,on
185、ly a sub-set of the full display information is needed and available.Example signalsMotor powerBattery chargeSeatDoorDampersDCDCAnti-rollBatteryAir springsClusterRear seat displayAmplifierInverterPropulsionChassisGatewayCentral displayFacing significant network architecture and design challenges CON
186、TINUEDSPONSORED BY18GenerativeEach of the day-to-day challenges and decisions that occur during the network design phase of E/E systems development can have widespread,cross-domain effects that are difficult to predict or even fully understand.Connecting the many disciplines enables designers to und
187、erstand the downstream impacts of their decisions during development and is critical to accelerating the vehicle development process.Networks design considers and implements many elements vital to both assuring correct vehicle functionality and protecting the entire system from incorrect sub-system
188、behavior.It is important to select a solution that consistently and correctly generates the configurations and documentation used in the development and validation of each ECU making up the full system.Capital Networks has been developed to address the specific needs of the design of vehicle network
189、s.Bringing together learnings from its predecessors,which were used by multiple OEMs across the world,and the AUTOSAR flow and framework,which also includes many years of industry learning,to offer the most robust networks design solution.The criticality of embedded software developmentEffectively d
190、esigning,testing and deploying on-board software is a key priority for automotive companies across the world.By following a model-based approach in a common environment for system and software engineers,this process can be significantly improved.There are several key tasks embedded software engineer
191、s must accomplish:Create clear requirements and functional definitions to improve downstream software quality Develop accurate,verified software architectures Design,simulate,implement and verify software components Develop embedded software for automotive ECUs that satisfy functional safety and cyb
192、ersecurity requirements Integrate AUTOSAR basic and application software Configure AUTOSAR embedded software and enable ECU flashing Simulate and verify embedded software implementations Capitals new embedded software development tools can help customers establish high quality software and adherence
193、 to the industry standards of safety and security.This is done by using a software architecture-driven flow,integrating network design into the development process and accelerating AUTOSAR-based virtual verification and deployment of software on an ECU.This virtual verification approach has great po
194、tential to positively impact the quality and speed of embedded software development and is the subject of the next section.AUTOSAR and SiemensAUTOSAR is the go-to standard to enable the digital thread for development of automotive embedded software and a key technology enabler for generative softwar
195、e development.Read this blog post by Henrik Olsen is Product Line director for the Embedded Software solutions in the Integrated Electrical Systems segment in Siemens Digital Industries Software,to find out more about Siemens Premium Partner status with AUTOSAR.CLICK HERE TO VIEW THE BLOG POSTFacing
196、 significant network architecture and design challenges CONTINUEDSPONSORED BY19Deploying safe and secure automotive-grade embedded software with V&V Workflow and verificationDevelopment methodologies and verification and validation(V&V)tools have advanced over the past few decades.Today,the Model Dr
197、iven Development(MDD)methodology and X-in-the-loop(XIL)verification are well-established as an effective means to develop safe and secure vehicle E/E subsystems.In the MDD systems engineering process,or generative workflow(figure 13),a model of the ECU is tested against a model of the vehicle system
198、s communication networks,sensors,actuators and plant environment that surround the ECU:the model-in-the-loop(MIL)level of abstraction.Once the model is validated,C/C+code is auto-generated from it and retested:the software-in-the-loop(SIL)level of abstraction.Eventually,the generated code is integra
199、ted into ECU hardware and platform software(firmware)and retested:the hardware-in-the-loop(HIL)level of abstraction.HIL-level testing can also be performed utilizing models of the ECU hardware:the so-called virtual hardware-in-the-loop(vHIL)level of abstraction.The different abstraction levels of XI
200、L configurations found across the MDD/XIL workflow are summarized in(figure 14).The range of accuracy(or fidelity)of the various XIL configurations can be quite wide.The vHIL configuration that leverages virtual ECU simulation technology covers the broadest range.In the vHIL configuration,the accura
201、cy of the ECU hardware model can scale whereas the platform and application software remain the actual code that deploys in the final vehicle(similar to HIL).This facilitates testing final production software on a platform that is optimal for the verification intent.With advanced MDD tools,integrati
202、on can also be generative in the workflow.Test benches and test automationThere are two major elements in the MDD/XIL testing architecture:the test bench and the test automation software that executes test cases(figure 15 next page).Figure 13.The generative MDD/XIL workflow produces correct systems
203、using automation.Figure 14.Test automation software sequences the SUT and accesses data within it using interfaces exposed by test benches.SPONSORED BY20Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDTest bench Testing an XIL system begins at the test bench.The test b
204、ench is an abstraction that provides the ability to execute a system under test(SUT)and access the data in it.The SUT includes ECUs,networks,mechatronic hardware and other simulated parts of the system.Each type of data or access requires a different interface and the information is configured and m
205、anaged by different specialized tools from different vendors.For automotive E/E subsystems,the primary data and accesses of interest include:Signals and parameters in embedded software and simulation models Data from the diagnostic functionalities of ECUs Measurable variables and calibration data in
206、 automotive software Data controlling fault and error-injection in the SUT Signals encoded into messages communicated over an automotive networkFigure 15.An overview of XIL test bench configurations.SPONSORED BY21Test automation softwareTo support the testing sequence or test case,test automation so
207、ftware utilizes the interfaces exposed by the test bench to access the data and exercise the systems functionality.The test cases must have enough coverage to V&V all aspects of the system that are applicable at each phase of the MDD/XIL workflow.Testing challengesThe idea of using computers to auto
208、matically transform modeled functions into production quality embedded C/C+code was once considered impractical,yet is now well-established as the most effective way to develop software.However,because of several factors such as the tiered ecosystem where several teams in different companies collabo
209、rate over large process gaps,the sheer complexities involved in developing modern E/E systems and the slower pace of standardization relative to the pace of new methodology adoption,there are large disconnects between V&V at the model level and V&V at the implementation level.It is clear this lack o
210、f test re-use is a significant issue.A huge business ramification is a reduced amount of V&V coverage if every test case is not converted or adapted to each level of abstraction.This causes issues in both directions:production code is not exercised against all important functional scenarios that are
211、 validated at the model level and an overreliance on expensive HIL equipment that is not always available to every software engineer.A larger business issue is the problems not found early in a project when they are less expensive to fix.Even worse,issues uncovered in the field can be disastrous to
212、the business.Factors that affect test re-useThe main factors that contribute to the lack of test re-use include:Levels of abstraction of the data and signals in the test benches Modeling and programming languages Sequencing and control over the various specialized tools Means to stimulate and trace
213、the SUT Lack of standardization If these factors are not addressed adequately,equipment and tool dependent tests are developed multiple times,often by different people with varying skill sets.Different levels of data abstraction A major challenge is when signals are represented,encoded and interface
214、d at different levels of abstraction as the system is re-integrated moving from MIL,SIL to HIL.For example,a signal might be encoded as a double precision software variable at the MIL level,yet it ultimately will be realized in a CAN network message at the HIL level or as a calibrated 32-bit integer
215、 at the SIL level.How does a test case consistently access data that changes in its data structure during a project without any modifications?Different languages In the systems engineering process,different languages are used.A modeling language such as Simulink,Simcenter Amesim software,the UML,or
216、Modelica might be used at the MIL level whereas a programming language like C/C+is typically used at the HIL level.How does a test case read and write values in a SUT consistently during development as the languages change?Figure 16.Shift-left test and verification using a digital twin to find probl
217、ems earlier.Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDSPONSORED BY22Different tools and simulators Many different tools and simulators are needed to validate a modern ECU.Simcenter Amesim might be used in a MIL level testbench to describe a plant model and Capita
218、l VSTAR Virtualizer could be used at the vHIL level.Automated driving tests require environment scenario tools like Simcenter Prescan software.Starting up an HIL rig is very different from launching a virtual ECU.These are just a few examples.How does a test case know how to configure,initialize and
219、 control the various tools used as a project progresses?Different means to simulate and trace Each tool has a different way to extract signals and parameters,obtain data from diagnostic functionalities,measure variables and access calibration data,provide a means to control fault and error-injection
220、 and parse and extract signals packed in automotive network messages.How does a test case consistently stimulate and trace data as test benches change?Lack of standards Without standardization,test case re-use is simply unattainable because there is no standard way to:Communicate between test cases
221、and test benches Describe,configure and initialize test benches Map and access data in test benches Generate test artifacts automatically using MDD model transformationsThe business problems related to a lack of standardization are:No ability to efficiently exchange test cases and test benches betwe
222、en OEMs and suppliers Increased training costs because know-how cannot be easily transferred Prohibitive costs to switch between testing technologies and products Verification engineers cannot combine the best test automation software with the best test bench productsIssues with direct-coupled test
223、architectureIf the test automation software is directly coupled to the test bench using a rigid interface,whether it is standard or not,test re-use is not possible across the MDD/XIL workflow.Another drawback of direct-coupled test architectures is that the verification apparatus does not readily su
224、pport a heterogeneous configuration where MIL-level test benches can be mixed with HIL and/or vHIL level test benches.These heterogeneous configurations are needed to efficiently test multi-ECU systems,which are typically required to validate modern E/E systems for ADAS,ADS and AV.Figure 17.Several
225、factors contribute to the challenges within the MDD/XIL workflow.Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDSPONSORED BY23MIL level workflow with direct-coupling The MIL level workflow that uses direct-coupling starts with the development of test cases that are ri
226、gidly connected to the first MIL level test bench.Everything appears good enough.However,when you consider that different representations of the system are possible at the MIL level,you quickly discover rigid interfaces do not support test re-use because the interfaces do not match.For example,if an
227、 MIL level system#1 is modeled using language#L1,data type#D1 and tool#T1,its test bench interface#I1 will not match the interface#I2 for a MIL-level system#2 that uses language#L2,data type#D2 and tool#T2.XIL level workflow with direct-couplingBy examining the rest of the MDD/XIL workflow with dire
228、ct-coupled test benches and test automation software,the problems expand significantly due to many different languages,levels of data abstraction and the number of different specialized tools that must be controlled(figure 16).It is most certain that none of the downstream test benches will expose i
229、nterfaces that are compatible with the original MIL level test benches.In a direct-coupled test architecture,test development must be performed multiple times,most likely by different groups.This means function development is more isolated from ECU integration.Standards that support test re-useOpen
230、standards such as the Association for Standardization of Automation and Measuring Systems(ASAM)XIL and functional mockup interface have emerged to support testing artifact re-use and provide a common test automation architecture that promotes interoperability between testing tools from different ven
231、dors.These standards are very effective at reducing development and training costs.The standards are more effective when combined with an MDD/XIL workflow methodology that automatically produces testing artifacts as normal by-products of systems integration efforts using institutional rules and mode
232、l transformations.Figure 18.Interfaces across the XIL-levels do not match when data,languages,or tools change.Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDSPONSORED BY24When used in the MDD/XIL generative workflow as tool profiles,architecture standards such as AUTO
233、SAR can further maximize effectiveness and quality.Several professional-grade AUTOSAR runtime software and associated development tool solutions exist from different vendors.ASAM XIL ASAM XIL is an API standard for the communication between test automation tools and test benches.The standard started
234、 in 2009,as an effort to standardize HIL and has advanced to cover other test bench configurations used in the MDD/XIL workflow.XIL indicates the standard can be used for all in-the-loop systems.The most recent release is ASAM XIL version 2.1.0.A beneficial contribution of ASAM XIL in terms of busin
235、ess value is the ability to develop tests early in the development process when issues are least expensive to rectify.Other ASAM XIL values include:Support for test case re-use by decoupling test automation software from test hardware Interoperability between different vendors of test automation sof
236、tware and test benches Significant reduction of testing efforts Longer term protection of testing investments Common way to setup and initialize a test bench Collection of time-aligned trace data and a specification of its data format Ability to inject faults and errors into the SUT Support for test
237、 event and triggeringFunctional mockup interface(FMI)FMI is an open tool independent standard that is broadly supported by many tool vendors to support model exchange and co-simulation of dynamic models using a combination of XML files and compiled C-code.The XML and C-code is bundled in a functiona
238、l mockup unit(FMU).These FMUs are used during V&V to represent the sensor,actuator and plant environment surrounding a distributed E/E subsystem.FMI has been driven by a European Union(EU)Information Technology for European Advancement(ITEA)2-funded project,called MODELISAR.ASAM XIL-MAThe FMI initia
239、tive cooperated with the ASAM XIL initiative in the MODELISAR project.This cooperation helped standardize the way simulations are setup and executed to accomplish the coupling of simulation tools with testing tools across the MDD/XIL workflow.The results were embodied in an internally named result c
240、alled FMI for applications.ASAM and MODELISAR decided to join this part of their activities to develop a single standard,resulting in ASAM XIL-MA.The major goal of ASAM XIL-MA is to allow test automation tools to control simulation tools and access simulation models executing in them.ASAM XIL-MA is
241、extracted from ASAM XIL and abstracts test automation tools from test benches for this purpose.AUTOSAR The AUTOSAR partnership is an alliance of OEM manufacturers,tier 1 automotive suppliers,semiconductor manufacturers,software and tool suppliers.Considering the different automotive E/E architecture
242、s in current and future markets,the partnership establishes a defacto open industry standard for an automotive software architecture.A contribution of AUTOSAR that facilitates test re-use is the ability to describe architectures and their configurations in automotive E/E systems to provide the requi
243、red formal model transformation targets in the MDD/XIL generative workflow.A better test architectureTo combat the inherent testing challenges described here,a test architecture centered on standards and augmented with automated model transformation in an MDD/XIL generative workflow is key.Mapping a
244、nd configuration framework ASAM XIL is architected into two major parts(figure 17):1.A test bench for the simulation models,ECU data(for example,parameters,variables and diagnostics),electrical error simulation and the automotive networks.Deploying safe and secure automotive-grade embedded software
245、with V&V CONTINUEDSPONSORED BY252.A mapping and configuration framework that supports the mapping of units,data types or variable identifiers,triggering,actions,measurement,logging and other management facilities and services related to communication to the test bench such as initialization,ordering
246、 and sequencing.The test bench part of the architecture provides standardized interfaces to the different types of tools with specific test bench ports.These ports offer standardized access to ECUs,including interfaces for:Calibration Measurement Model access Diagnostics Electric error simulation Au
247、tomotive networksThe most challenging task of decoupling test automation software from test benches is facilitated by the ASAM XIL mapping framework.It allows data in a test bench to differ in value and type during the overall MDD/XIL workflow.The framework isolates the differences to different mapp
248、ings of values between the test cases and the test benches.Examples include abstract identifiers to concrete identifiers,physical units to physical units and data types to data types.By providing a new mapping for each different test bench,the test case remains unchanged and can be re-used directly
249、across engineering phases.The test bench ports are only supported in ASAM XIL 2.0 for compatibility with ASAM HIL and to provide functionality that is currently not provided by the framework layer.The major change in this area of ASAM XIL 2.0 is to introduce port independence to test cases by using
250、an object-oriented access to variables on the test bench and an abstraction of ports in the framework layer.Based on these variable objects,the framework also provides objects for port-independent signal recording,signal generation,event watching and triggering.ASAM XIL thus effectively provides an
251、adaption layer between the test cases and the different XIL test bench configurations in the MDD/XIL workflow.This allows the verification engineer to test any MIL,SIL,vHIL,or HIL test bench configuration using the same test case by inserting its corresponding mapping and configuration counterpart b
252、etween the test case and the test bench(figure 20,next page).Generative MDD/XIL workflowCombining ASAM XIL,FMI and AUTOSAR provide all the formal ingredients required for automated model transformation to create a generative MDD/XIL workflow.With the addition of a set of institutional rules,it is po
253、ssible for automated tooling to take test case descriptions,function models,environment Figure 19.ASAM XIL provides a flexible standard test architecture.Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDSPONSORED BY26models and architecture models that are produced duri
254、ng normal system design efforts,and generate the test benches,mappings and configurations required for automated V&V regression testing.The workflow starts at the MIL level of abstraction and generates test artifacts(figure 19).It is important to note that all the models conform to some formal domai
255、n-specific meta-model,and the map and configuration descriptions correspond to the function and environment model test benches for MIL level testing.After the function model is validated at the MIL level,it is used as input for automatic integration in an AUTOSAR-based platform using another set of
256、rules(figure 21).Note that all models conform to some formal meta-model.The additional map and configuration descriptions correspond to the ECU test bench.Figure 21.The MDD/XIL MIL-level workflow using ASAM and FMI standards is straight-forward.Figure 20.Test cases are reusable across MDD/XIL config
257、urations using ASAM XIL mapping and configuration layers to adapt test bench interfaces.The test bench,map and configurations for the environment model are re-used directly from the MIL level test bench.FMI co-simulation is used to connect and execute the environment model and ECU simulation(for the
258、 case of vHIL).Results and conclusionThe test cases developed during design can be re-used through to production ECU testing and ultimately for automated regression V&V of future software updates deployed into the field(figure 23).There are several valuable business benefits this testing architectur
259、e and generative MDD/XIL workflow affords:Problems are found earlier in car projects when they are least expensive to fix Test cases are re-used across the entire MDD/XIL work-flow,preserving testing investments Increased V&V coverage increases safety,enhances security and finds problems before they
260、 are deployed into the field An automated and generative MDD/XIL workflow increases quality by using model transformations that are correct-by-design and it reduces development,which shortens time-to-market OEMs and suppliers can efficiently exchange test cases and test benches,which saves cost and
261、time Decreased training costs because standards-based know-how is more easily transferred Verification engineers can combine the best test automation software with the best test bench products because of standard interoperability and switching between testing solutions is much less expensiveDeployin
262、g safe and secure automotive-grade embedded software with V&V CONTINUEDSPONSORED BY27 Tests can include multiple levels of abstraction in a heterogeneous configuration this is useful when validating the distributed multi-core,multi-ECU E/E systems found in modern ADAS,ADS and AV vehicle systems Mult
263、iple,cross-discipline interface requirements are satisfied with standardized access:calibration,measurement,diagnostics,networking,tracing,stimulus and fault-injectionFuture workACOSAR The main goal of ACOSAR is to develop a non-proprietary real-time(RT)co-simulation interface.ACOSAR is an ongoing p
264、roject.Real-time testing,in particular mixing actual and virtual testing components together,is an important use case(co-simulation of RT and non-RT systems).Because of the inherent need for network protocols in such a configuration,ACOSAR could potentially fill the gap of the missing network protoc
265、ol specifications within FMI.It is considered that ACOSAR will provide a so-called FMI for RT co-simulation.System structure and parameterization System structure and parameterization(SSP)is a developing standard that should be usable in all stages of the MDD/XIL workflow.The standards effort is coo
266、rdinated with the FMI and ASAM standards.The goal of SSP is to provide a standardized format to represent a connected set of components.These components for example,can be FMI-based simulation models and ASAM testing artifacts.This would provide for a more complete automation and a standard way to d
267、escribe and parameterize test configurations if the MDD/XIL workflow utilizes SSP as a standard description format.Going forwardThe complexity of all E/E architecture domains will continue to increase in the future.Automotive manufacturers must deliver and integrate numerous components that make up
268、highly complex,connected vehicle features to keep up with todays demands.The increasing number and sophistication of these components calls for advanced electrical,network and software engineering solutions to help keep up with the complexity and shortening product development timelines.Today,innova
269、tive electrical systems engineering solutions can help automakers by automating development processes,while frontloading capabilities will help companies accelerate vehicle development,spur innovation and lower development costs.Figure 22.The MDD/XIL workflow reuses tests across XIL-levels using for
270、mal standards.Figure 23.A MDD/XIL workflow that uses a standard test architecture supports test case reuse.Deploying safe and secure automotive-grade embedded software with V&V CONTINUEDSiemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering,man
271、ufacturing and electronics design meet tomorrow.The Xcelerator portfolio,the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software,helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new ins
272、ights,opportunities and levels of automation to drive innovation.For more information on Siemens Digital Industries Software products and services,visit or follow us on LinkedIn,Twitter,Facebook and Instagram.Siemens Digital Industries Software Where today meets tomorrow.STAY CONNECTEDCLICK HERE TO VISIT OUR WEBSITE