Transcription
DIGITAL INDUSTRIES SOFTWAREBringing automotive softwaredevelopment in-house: a shiftinglandscape for OEMs and supplierssiemens.com/autosar
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersContentsExecutive summary 3Trends in automotive systems design necessitatea new approach 4Meeting the challenges of modern automotive E/Esystems development 5AUTOSAR Classic vs. AUTOSAR Adaptive 5The evolution of automotive software architectures 6The future of software-defined vehicles 10Software integration and verification 12The software factory: developer-centric systemsSiemens Digital Industries Softwaredesign 14Considerations for establishing a software factory 15Conclusion 162
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersExecutive summaryFor automakers, the race is on to develop and bringThe good news is that modern design methods andto market competitive feature sets for highlysolutions support and enable new ways of working,connected electrical and electronic (E/E) architec-helping to eliminate data silos, reduce the risk oftures, to meet consumer demand for exceptionalerrors and streamline embedded software develop-driving experiences and to create market differentia-ment. In this whitepaper, we will explore:tion. New vehicles are characterized by unprecedented complexity requiring electronic control units(ECUs) with more processing power than ever.To that end, OEMs are reversing the historical trendsfor outsourcing ECU development to Tier 1 suppliersand bringing development in-house, particularly fordevelopment associated with proprietary intellectual property (IP) and competitive feature sets.1. How work split between OEM and Tier 1suppliers is changing for embedded softwaredevelopment.2. Which systems are leading this change, and howdevelopment processes and the skills requiredwill be impacted.3. How generative tooling supports developmentHowever, this shift comes with a new set of chal-within new teams and reduces the reliance onlenges. Historically, OEMs employed teams ofspecialists.specialized engineers using highly specific tools,often working in isolation. Each department had itsunique, optimized workflow, which made effectivecollaboration difficult. Even if OEMs bringembedded development in-house, the miscommunication that can result from working in silos can leadto missed or misinterpreted requirements. As vehicles have become more complex, OEMs will losetime and money and sacrifice quality if theycontinue with their traditional operating methods.Siemens Digital Industries Software3
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersTrends in automotive systemsdesign necessitate a new approachMultiple trends are impacting the automotivesame car can use the vehicle differently withoutindustry today. Not only is the amount of electrifica-mechanical modification. This model provides bothtion and electronic complexity within vehiclesopportunity and obligation to provide better cyber-increasing, automakers must also grapple withsecurity, enhanced software features and the abilityincreasing software complexity and stringentto respond to and accommodate consumer choice.governmental regulations. Complex software-intensive features such as driver assistance and autonomous drive, high-quality media and infotainment,along with the demand for an advanced user interface and experience, put tremendous pressure onautomakers to innovate rapidly.As vehicles become more complex, the traditionalway in which OEMs have operated is unsustainable.Rather than employing specialist engineers thatwork within specialist teams using specialty tools,OEMs must find ways to work collaboratively andeliminate data silos that can lead to miscommunica-Adding to the complexity, multiple concurrenttion and errors. Often, technical information is stilltechnical transformations are under way withcommunicated using manual processes, and therespect to the software-defined vehicle. New termi-exchange of data between teams is inefficient or, innology is appearing to signify these changes, bothsome cases, nonexistent, resulting in misinterpretedto customers and the industry at large, to show howrequirements and cumbersome change manage-OEMs are becoming increasingly software focused.ment processes. All of this impacts product quality,Examples include “Automotive cloud,” “CAR.OS,” anddrives up costs and affects revenue.“Subscriptions.”To achieve the efficiency, speed, accuracy and“80% of product innovationand differentiation is nowelectrical, electronics andsoftware.”Siegmar HaasisDaimler R&D CIOOptional content, delivered as “Apps,” is availablethrough over-the-air updates as vehicles connect toan automotive cloud. For example, the option toenjoy heated seats may become a subscription-based service. This means two owners of theSiemens Digital Industries Softwarequality necessary to develop these highly sophisticated systems, data silos must be eliminated – bothbetween specialist teams as well as functionaldevelopment teams such as the departmentsresponsible for the powertrain, chassis and vehiclebody.“The Automotive industryis wasting millions ininvestment due tooperating in silos.”Elevenci Automotive ConsultingMarch 20204
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersMeeting the challenges of modernautomotive E/E systems developmentThe traditional approach to adding a new feature isupdates enable software fixes directly to customers,to add a new ECU that enables that feature, whichreducing this cost, but places even more emphasisrequires additional harnessing, capability, connec-on a robust validation phase, as the vehicle is nowtions and software, further driving up vehicleupdated away from the workshop and its trainedweight, complexity and costs.technicians. OTA updates also require an onboardWhat’s more, complex specialist toolsets often lackautomation and connectivity, impacting productivity. Making changes is easiest if a problem iscaught early. The cost and complexity of refiningand improving the product increases through thedevelopment process. A heavy dependence onphysical testing further increases costs and candelay time-to-market. The software developmentsoftware update process, driving memory andprocessing resource considerations, and requiringrobust Cybersecurity, such as R155 and R156 frameworks (UNECE WP29 legislation). The increasingfeature content of modern vehicles means that thisis also aligned with expanding functional safetyconsiderations, and more powerful and sophisticated computing power.process usually needs to support the full vehicleThankfully technologies such as AUTOSAR Classicdevelopment and validation plan with increasingand AUTOSAR Adaptive are available to supportfunctionality at specified phases, however usingtransitional automotive functionality and high-func-only those phases to validate the software can resulttional safety use cases, as well as service-oriented,in costly late changes. Software developmenthigh-compute functionality. Powerful multicoreusually follows an agile development process whichmicrocontrollers and more sophisticated micropro-includes continuous integration and testing.cesses with cores optimized for different types ofTraditionally, the only way to update vehicles oncesold was through Recall or Technical ServiceBulletins at the dealers, at high cost to the OEM andcomputing tasks are also available. These innovations are enabling the evolution of electronic architectures in vehicles.inconvenience to the customer. Over-The-Air (OTA)AUTOSAR Classic vs. AUTOSAR AdaptiveThe continuous development of AUTOSAR has madeit the preferred design methodology for system-levelapplication design. AUTOSAR provides the ability to:1. Define the overarching functions and extract2. Transport diagnostics data and at the ECU level.3. Interoperability then both on the bus levelbetween ECU, as well as on the application levelon top of the RT.scheduling of a task or a runnable in the core.Siemens Digital Industries Software5
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersThere are three main parts of AUTOSAR: AUTOSAR3. AUTOSAR Foundation is underneath both ofClassic Platform, AUTOSAR Adaptive Platform, andthese platforms and contains the foundationalAUTOSAR Foundation. While they may seem to berequirements. These requirements capture thecompeting for attention, in reality, they complementinteroperability between the two platforms.each other.1. AUTOSAR Classic is designed for the Classiccontrol ECU, which controls legacy features forthe vehicle. AUTOSAR Classic has a staticallydefined function that is updateable throughsoftware updates.2. AUTOSAR Adaptive is used for computationand the fusion of data, and it enables the legacyPOSIX and Linux ECUs such as infotainmentclusters and telematics to be described at afunction system level, then derived down to theimplementation and applications.What Is AUTOSAR?AUTOSAR is based on the Open Systems andInterfaces for Distributed Electronics in MotorVehicles (OSEK), a German standard developedin the late 1990s. The AUTOSAR partnership wasfounded in 2003 as an international standardto enable the corporation on standard software for automotive vehicles. Today, it is thede facto standard for ECU platform software.Apart from the specification for embeddedsoftware implementation, AUTOSAR provides abase format on data exchange: the digitalthread. It also provides for multiple handoffsbetween different tools throughout development, so that each tool can enrich the datamodel and provide more granular information.The evolution of automotive softwarearchitecturesAs recently as 10-15 years ago, E/E architecturesconnected to both, as well as a gateway. OEMs mustcommonly consisted of two or three main CANalways consider cost, and this is one of the factorsbuses, with some function-specific LIN bus exten-constantly driving consolidation of functions intosions. A gateway would connect the CAN buses andfewer ECUs. For example, cruise control was origi-often, other ECUs would connect to pairs of CANnally an optional ECU when the feature was newbuses where data needs were high or highly timeand novel and later became a software function incritical. Initially, adding more features to vehiclesan engine controller or a braking module as optionwould require additional ECUs for hosting each newtake-up became common.function, and as the number of ECUs increased, sodid the number of CAN buses. Each CAN bus, ornetwork, typically expands with ECUs of relatedfunctions, until bus load becomes impractical whenit can be split, for example, Powertrain and ChassisECUs, with potentially an ABS/Braking ECUSiemens Digital Industries SoftwareThe architecture has evolved to having severalfunctionally oriented networks, some of which mayhave been “upgraded” from CAN to CAN FD orFlexRay to support higher data rates, and withfunctional consolidation driving the use of ECUs6
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and supplierswith more powerful compute. Initially, such consoli-model to accommodate additional functionality indation could be managed with Tier 1 suppliersthe future is challenging. Centralizing the architec-developing equivalent functions, but this hasture and leaving headroom in a few ECUs enablesbecome costly to OEMs, and is an inflexiblethe majority of the ECUs to run in an optimizedapproach. Increasingly, OEMs are looking to focusmanner (see figure 1).consolidation on a single Domain Controller ECU perfunctional domain, often taking more involvementin the engineering of these ECUs. The E/E architecture is organized with these ECUs at the head ofeach domain; however, now some OEMs break thenetwork connection to the gateway and insteadconnect the ECUs to a backbone network, which isoften now switched at the gateway – thanks to theadoption of high baud rate networks, such asEthernet, which reduced latency between domaincontrollers.ECUSensor/Actuatorcentralized and zonal architectures is increasinglycommon today. Concentrating the maximum functions into the central and sometimes zonal ECUsenables the outer ECUs to remain relatively simpleand lower-cost. Often, these will leverage theAUTOSAR Classic Platform and be quite similar to theECUs used in vehicles for many years now. ZonalECUs can be used as I/O concentrators, mostlyserving as gateways, which could be an AUTOSARClassic or AUTOSAR Adaptive function. MultipleIn service-oriented architectures, the goal is to beOEMs are also hosting some functions, often drivingable to move functions around easily, leaving head-a mix of AUTOSAR platform types across multipleroom in the ECUs to accommodate new function-cores. Central compute commonly includes someality, as needed. This should be accommodated inhigh-power compute and potentially sophisticatedthe center of the vehicle so that future updatesSoC type processing, enabling a combination ofdon’t have to be distributed across all ECUs within aAUTOSAR platform types as well as other platforms,vehicle. Typically, ECUs have optimized amounts ofsuch as Linux, to optimize the hosting of differentprocessing power and memory, and changing thattypes of processing.Multi-bus gatewayarchitectureGatewayAs depicted in figure 1, the evolution towardsFunctional domain controllerarchitectureZonal architecture withcentralized computeFunctional domaincontrollerCentralized genericcomputeZonal controllerLINCANMOSTLVDSCAN FDAutomotive ethernetA 2BAutomotive SerDes/GMSLFigure 1. This diagram illustrates the evolution of E/E architecture types.Siemens Digital Industries Software7
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersAdditionally, for several years, OEMs have beenOEMs have started to become more strategic withreevaluating their make-or-buy decisions – vacil-respect to ECU development, and bringing brand-de-lating from the idea of spinning out the electronicsfining software functions in-house. This providesbusinesses to buying and working with Tier 1 suppli-more control and enables them to work in a strategicers (see figure 2). Competitive tension led to OEMsway with long-term partners. In-house developmentfocusing on electrical architecture, network design,has implications for the CAR.OS and its ability toand specific ECU components. In recent years,receive over-the-air updates. Over the life of thethey've become involved in developing the softwarevehicle, updates will be necessary to fix bugs, addarchitectures and writing some of the applicationsnew functions, and improve cybersecurity. Whereasthemselves, as well as integration. In some casesmany of the I/O functions, such as switches andthey've moved from just specifying certain compo-actuators, may require new functionality to benents of an ECU to specifying the full bill of mate-enabled at a higher level, base actuators and sensorsrials, and even designing the PCB layout. A few alsowon’t change much, so traditionally sourced ECUsdesign the microcontrollers, as is the case for Tesla’swill continue to perform well over time.self-driving ECU. Still, many ECUs are conventionallysourced against a set of requirements.OEMs taking on more designresponsibility of selected ECUs Building new specialist teams New commercial modelsECUSensorActuatorand etc.(combination)SoftwareupdateOften over airOver airOver airTo add/update(mainreasons)Bug fixesNew usecases forfunctionsTraditional rolesOEMTier 1Tier 1(collaboration)Tier 2E/EarchitectureNetwork designSW architectureECU BOMspecificationSW implementationMCU designPCB designECU manufactureIn house SWIn house ECU designBug fixesBug fixesCyber security Cyber securityNew functions New functionsNew dataNew dataroutingsroutingsFigure 2. ECU development collaboration requires centralized and zonal architectures.Siemens Digital Industries Software8
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersTable 1 shows how collaboration on ECU design,that it’s faster and more efficient to design highmanufacturing, and integration has changed overcompute ECUs in-house.the years. To remain competitive, OEMs are tesFew ECUS, largelyindependentfunctionsOEM: libraryfunctionsTier 1Tier 1Reducing OEMvertical integration,Tier 1 business unitsspun outTier 1Tier 2OEM: software/controls modelsOEM: integratingsoftware forspecialist ECU'sTier 1OEMs insourcingsoftware (IP)development forbrand experiencerelated functionsTier 1Tier 2OEM: branddefining functionsTier 1: commodityOEMTier 1OEMs insourcingdesign of highcompute ECUs,mostlyOEMTier 1OEMTier 1Tier 1Tier 1Tier 1Tier 2TodayTier 1OEMTier 1Longer termtrendsTier 1OEMTier 15 to 15 years agoSoftwareintegrationOEMTier 1OEMTier 115 years agoOEMTier 1Platformsoftwaree.g. AUTOSARECU HardwaredesignTable 1: ECU Development collaboration requires varying levels of vertical integration.Following are definitions of new terminologyused to describe the shift toward in-houseembedded software development:and is used for software updates and to1. Apps: Features on vehicles are delivered asVolkswagen's VW.AC.perform compute for some onboard functions,when connectivity allows. An example isapplications, enabled by vehicle functions.5. OEM.OS: The OEM software platform baseImportant to this trend is the ability to addis used by an OEM group, and consists of aapps over the life of the vehicle. Examplescombination of OS and middleware, organizedinclude BMW’s Digital Key and High beamstrategically according to architecture andassist or Tesla’s Dog Mode.functions. Examples include Volkswagen’s2. Subscriptions/Features-as-a-Service:Similar to apps, features are delivered as aservice via paid subscriptions.3. OTA updates: The ability to perform softwareupdates without visiting the physical servicecenter. These may include updates to improvecybersecurity, functional updates, additionalfeatures, or media.4. Automotive cloud: The Automotive CloudVW.OS and Volvo’s VolvoCars.OS.6. Software factories: OEMs are formingspecific software development sites, oftenseparate from traditional product developmentand sometimes set up as separate businesses.This enables software-specific processes andmethods, new supplier collaboration models,and the ability to recruit software developers. Examples include BMW’s Car IT andVolkswagen's CARIAD.is a cloud for series production cars in serviceSiemens Digital Industries Software9
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersThe future of software-definedvehiclesSeveral considerations contribute to the successfulModel-based systems development enables adevelopment of automotive software:holistic assessment of the E/E architecture devel-1. The digital thread: A digital thread is a singleset of data that is accurate and consistentthroughout the design lifecycle, giving allstakeholders insight into decisions made acrossdomains. Using the digital thread, issues can becaught and addressed early in the design process,accelerating design while reducing rework andassociated costs.2. Collaboration with IP protection: Several teamsoped in the context of the target platform. Itabsorbs the system models and all of the requirements impacting development, while enablingdevelopers to optimize design for downstreamimplementation of Electrical Distribution System(EDS, wiring harness), hardware, and software.Using a digital thread, developers can dynamicallyassess the design against key criteria and in thecontext of the mechanical targets. This leads to theability to refine architectural proposals for imple-will contribute their IP to the software design, somentation teams who are developing the finalwe must ensure IP protection for the organiza-product, while keeping costs in check.tion’s IP as well as Supplier and Partner IP.3. Developer centric development environment: The software developer environment mustbe developer-centric and attractive, enablingdevelopers to utilize their skill sets effectively.4. Structured software architecture: A structured software architecture is required to controlresource usage over the system: MCU, CPU, loadbalancing between ECUs and multi-cores, and soon. This requires a higher level of control overthe application.5. Configuration: For configuration, future“Software will accountfor 30% of total vehiclecontent by 2030, upfrom about 10% today.”McKinseyPart of the Siemens Xcelerator portfolio, SiemensCapital VSTAR is Siemens’ implementation of theAUTOSAR standard, and a complete offering with allthe tools and features required for rapid embeddedpersonal transportation needs will require a dif-software development using a model-based systemsferent set of configuration abilities. We will seedevelopment approach. Capital VSTAR reducesservice-oriented architectures, because functionshardware dependency and enables automotivewill be traveling over ECUs and possibly to thesoftware developers to work within an AUTOSAR-cloud over the versions of the vehicle and theaware environment as they integrate, test, andlifetime of the software-defined vehicle.analyze their next-generation automotive software.Capital VSTAR adheres closely to the AUTOSARmethodology and includes native support for theAUTOSAR Layered Software Architecture.Siemens Digital Industries Software10
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersFigure 3 illustrates the Capital VSTAR design anddevelopment flow.Implementation flows for software and electricalSystem models and E/E architectureE/EarchitectureImplementationsProposed E/E architectureNetworkSW implementationElectricalHarnessPublicationsE/E Centric Data & Process Management Domain Centric V&VCapital ManagerRequirements & SystemsSW architectureElectricalSoftwareHardware!"# %&' (")*' %&',-%'./0)1(&/# )*# '2/)(/*)345!"# %&./' ) #&6' #)7)8( %.&9):-,"' (%'./ ) # '2/)7)6#&'8' (%'./).8)/#%?.&B):&.%. ." Development of the electrical system(EDS or EWIS), the associated harnessesand services or shop floor publicationsArchitect and verify SW functions, network Architect and verify hardware functions.design and AUTOSAR based middlewareIntegrate HW, SW and NW models toconnecting SW applications to ECUverify system behavior and performanceElectricalElectrical distribution systemHarness design and M/FService and diagnostic docsSoftwareSoftware architectureNetwork designSoftware implementationHardwareMulti-board PCB and PCBSystem on ChipTeamcenterProduct Lifecycle Management – PLMFigure 3: E/E Systems development using the Capital flow.Capital’s development flow can be used as a blue-and provide the execution platform for theprint of the digital thread for the E/E systems devel-software.opment. In the flow, the mechatronics – the sensorsand actuators – are isolated early on to the physicalpositions of the vehicle. The electrical and the hardware flows are used to connect these ystemsengineerof the software, a software-centric data and processmanagement system is essential (see figure 4 ).DesignSW architectureCapital SystemsCaptureCSWCmodelsand codeIntegratesoftwareCapital els & testsSystemsmodelsSoftwaremodelsAllocated SWfunctionsTo address the increasing amounts and complexityE/EarchitectureE/EarchitectCapital SystemsArchitectTeamcenterDesignNetworkE/E topologyand sNetworksMatrixVerificationengineerCapital VSTARVirtualizerV&VKPI'sreports &analysesProduct Lifecycle Management – PLMFigure 4: Software-centric data and process management system.Siemens Digital Industries Software11
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersBy developing software in a platform context, youFor example, the Siemens Polarion tool can be usedcan frontload the process and create a contract-for requirements traceability and also to ensure thatbased, pre-validated software architecture. Early vali-the compliance evidence is in place. Refining thedation of the network communication system is pos-software architecture at the vehicle level andsible, and software integration is automated usingconnecting application communication to thethe AUTOSAR methodology, enabling you to attachnetwork design is the next step.each design step to an ALM-driven software process.Software integration and verificationSiemens’ Capital VSTAR is a highly compliantLet’s take a look at the various components:AUTOSAR implementation and tooling enables1. ECU extract. The ECU extract describes the func-streamlined ECU integration with a guided usertional connectivity used for configuration of theinterface, and automates software integration withmiddleware. The application and diagnostics con-an AUTOSAR methodology. Sophisticated configura-nections are defined, in a file or files, supportingtions are managed by a generative developmentexchanges between tools and technical partners.flow, enabling the development of high-perfor-2. ECU software. The ECU software in this contextmance embedded platform software that is scalable,safe and secure.is the functional application software that ishosted in this ECU. The integration tool uses thisIn figure 5, the AUTOSAR Classic platform is used forto generate application interfaces, network busECU basic software configuration and the applica-communication, etc.tion integration to target a scalable solution that issafe and secure.Software Centric Data & Process Management – ALMPolarionECUExtractECU allocatedsSys.elementsIntegrate softwareImport ECU extractECUextractBSWconfigCapital Networksor similar OEM toolECUSoftwareSW architectImport AUTOSAR software orlegacy refactored IntegratorIntegrate ECU software and configureAUTOSAR basic softwareECUfirmware,Verify softwareVerificationengineerAUTOSAR software authoringor similar model-based toolsTeamcenterCAUTOSAR SWCContract & templatesCapitalVSTARVirtualizerV&VKPI'sreports &analysesProduct Lifecycle Management – PLMFigure 5. Integration of ECU allocated software on top of virtual or physical hardware.Siemens Digital Industries Software12
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliers3. Interface to the applications: Following theintegration process, the interface to the applications is generated by the RTE.4. Application implementation: The applicationsimplemented and connected in the C code interface are used to build the binary.Capital VSTAR consists of the Tool and theEmbedded Runtime:1. The tool connects to the digital stream andprovides an automated workflow with thehighest visibility of integration status andsoftware behavior. The tool provides theAt the same time, you also have a virtual represen-configuration for the embedded softwaretation – a digital twin. We can use the digital twinand output for further development activi-for verification and to analyze application behavior,ties, such as calibration.to make sure that it behaves correctly. Additionally,the virtual environment enables you to investigateToolany issues and identify their root causes. The digitaltwin enables you to verify, analyze and report onwhether you have enough headroom for software,or if you’re running tight on resources, as well.The new OEM branded operating systems describe atechnology mix brought together by the OEM toserve as a technical base for their functional applications. This almost always includes both definedversions of AUTOSAR. As such, AUTOSAR will remainrelevant for the future, and OEMs’ future use cases2. The embedded implementation provideswill be defined and supported by these platforms.the required features to support theAs an example, Capital VSTAR is a completeapplication needs, based on the providedAUTOSAR compliant solution that supports thedevelopment of innovative features for today andthe future. Capital VSTAR provides:configuration, with the right properties forefficiency, safety and security.Embedded runtime1. Performance via tooling that puts the developerfirstSoftware Component (SWC) ApplicationsRuntime Environment (RTE)2. Automation and virtual validation for right-thefirst-time design3. The ability to reuse software functions withBasic Software (BSW)future MCU and CPU families4. Functional safety and cybersecurityMicrocontroller Abstraction Layer (MCAL)5. Fast deployment and multi-core support6. Efficient customer enablement, with deploymentand support servicesSiemens Digital Industries Software13
White Paper – Bringing automotive software development in-house: a shifting landscape for OEMs and suppliersThe software factory:developer-centric systems designThe rise in software factories requires organizationsestablished methodology for bus-level separation,to hire and retain more software developers. Often,where ECUs communicate over the bus interfacethis means a differentiated culture for the OEM, orthat’s defined either by the OEM’s communicationTier 1 making this change. An important part ofmatrix or by using a standard such as SAE J1939.establishing these teams and retaining the talent isthe use of processes and software tooling thatenable developers to be innovative and add valuewith minimum wasted effort and repetition. Suchtooling accelerates
There are three main parts of AUTOSAR: AUTOSAR Classic Platform, AUTOSAR Adaptive Platform, and AUTOSAR Foundation. While they may seem to be competing for attention, in reality, they complement each other. 1. AUTOSAR Classic is designed for the Classic control ECU, which controls legacy features for the vehicle. AUTOSAR Classic has a statically
