车辆架构的演变需要云就绪的ECU

/Vehicle ArchitectureEvolutionDemandsCloud-ReadyECUsThe future is here for automotive software and electronics,according to McKinsey & Co., with software-defined vehiclearchitecture fast becoming reality, aided by the disruptive forceof autonomous driving, connected vehicles, electrification ofthe powertrain, and shared mobility (ACES). The consulting firmpredicts that by 2030 — in about three to four vehiclegenerations — 70% of vehicles will have a software-definedarchitecture, and automotive companies across the value chainmust begin harnessing its potential now. /2/Vehicle architectural evolution is best understood by looking at milestones,as shown inFigure 1. Before 2017, classically driven vehicles were characterizedby discrete electronic control units (ECUs) and their embedded softwaredistributed throughout the car. These parts from various vendors wereessentially assembled by the OEM with little value addition from the softwareperspective. If an ECU malfunctioned or required an update, manualreplacement was required by qualified engineers at dealerships.Figure 1:Vehicle E/E architecture is evolving from legacy fixed-function or monolithic through domain and zonal to serverized and cloud-native goals.Software abstractedfrom hardwareEV optimizationvia software(BMS)Cloud-nativesoftwareplatformsScale-up ofcloudcomputeEnd-to end,cloud-nativeDevOpsSource of architecture innovation increasinglydriven by software, resulting in new value creationand business model opportunitiesOptimized HVsupportingup-integrationHPC* forprocessingintensive appsOn-vehicle computeaugmented by cloudSoftware-DefinedZONEReduce physicalcomplexity throughintelligent zone controlSERVERIZATION (FULL SVATM)Enable complex, continuouslyupdateable features and fail-operationalsupport for higher levels ofautonomySOFTWARE-DRIVEN INNOVATION20222026Cloud-NativeINTELLIGENT EDGEIntegrate the vehicle into the IoTthrough cloudconnectivity/intelligent edge2030+ Architectural Evolution*HPC: High-performance compute, e.g., Aptiv’s Open Server PlatformInitial Introductions into ProductionFUNCTION (LEGACY)Incremental mechatronicapproach to features notsustainableOn-vehicleArchitectureOn-vehicleSoftwareCloud andDevelopmentApproachWaterfallAgiledevelopmentmethodsHybridization &bolt-on HVComputeCentralization &up-integrationHardware-DefinedDOMAINSupport for significantnew functionality throughdomain up-integration2017 Architectural Evolution/By 2017, however, OEMs had begun thinking in terms of domains, such asbody control, powertrain, and infotainment, with some fashion of computecentralization.And this domain notion has now evolved toward a cross-domainphysical zone based electrical/electronic (E/E) architecture that up-integratesthe large number of discrete ECUs to utilize fewer, localized, higher-performancecompute systems.The reason behind this shift is the desireto reduce cabling, weight, and complexitywhile improving efficiency. However, theability to accomplish more by defining moreelements in software has opened to the doorto yet increasing complexity. OEMs continueto extend their zonal architecture towardserverization, leading companies suchas Aptiv to further reduce the number ofcompute units by integrating more softwareonto larger, high-performance compute(HPC) units.The cloud-enabled car of 2030 willcontinue performing the many critical real-time functions onboard, such as antilockbraking system code. Rather, the cloud willinstead assist via public or private cloudsetups in providing additional services suchas routing to available parking based oncurrent location or destination.The E/E architectural evolution hasalready come a long way on the timelinein Figure 1 and is now beginning to use anagile development model. Over the nextfew years, OEMs will adopt a softwaredevelopment and IT operations (DevOPs)type of environment that enables continuousintegration, continuous test, and continuousdelivery. The heavy lifting for this ability willbe done by containers. Whatis Containerization? /4/Containerization is the evolutionary step up from modularization,in which several software systems are examined to identify areaswhere “reuse” can be derived. Those areas are then isolated intodifferent modules. This enables development teams to clearlyunderstand the purpose of each module and, if the system fails,quickly find out what went wrong. The container packages suchmodules with operating system (OS) libraries and dependencies, soit has everything any hardware compute environment would requireto consistently run a lightweight executable.The up-integration of cloudcomputing technologiesinto vehicles to providenew features, services, andexperiences starts witheliminating existing ECUs byabstracting their functionality,modularizing, and containerizingthe modules for delivery. ContainersEase Management/Traditional software management in embedded systems is an expensivetask with possibly dozens of software solutions to update. These solutions aremonol