Today's vehicles come with a fair amount of software. Automotive software development and also the respective Application Lifecycle Management (ALM) are subject to certain drivers that carmakers should take into account in an autonomous, connected, electric and shared (ACES) ecosystem. By understanding these drivers, automotive companies can develop the right business capabilities and remain competitive. This second post in my series on "ACES ALM" helps with exactly this understanding.
Traditional ALM focuses on the performance of the software development process and the subsequent lifecycle management. Depending on the environment in which the development processes take place, the balance of speed, cost and quality shifts. Where some Silicon Valley startups seemingly do not have to worry about cost as long as they meet aggressive time-to-market goals, automotive suppliers for safety-critical applications are probably more cost-pressed and quality-aware. Drivers for ACES ALM are not different to traditional ALM. However, there are a couple of factors that have to be considered in addition or with different weight. So let us delve into the drivers, which can be broadly categorized along the four factors of ACES engineering business drivers, processes & methods, regulatory requirements, and IT strategy drivers.
ACES engineering business drivers
From the engineer’s point of view, ACES disrupts major components of the product architecture. Powerful domain controllers allow the execution of multiple parallel functions, which in turn requires an unbundling of function software from dedicated ECU hardware. The onboard computers are working closely together with enterprise IT backends, for example to feed the data-hungry algorithms with sensor data.
Separation of hardware and software. Traditionally, tier-1 suppliers deliver ECU (Electronic Control Unit) hardware combined with software as a single package. This leads to complex distributed systems with 50-100+ ECU’s connected via interfaces such as CAN bus or Ethernet. With OEM’s focusing on software and even operating systems as a core competency, new models are created such as OEM-specific OS or sourcing of software only. As an example, please refer to the Volkswagen Group with CARIAD developing the VW.OS (operating system / embedded) and the VW.AC (automotive cloud / enterprise).
Domain-controller architectures. The 50 to more than 100 ECUs in traditional vehicles pose challenges in cost, weight, space, security and complexity in the vehicle network and the development process. That is why the automotive industry is focusing on domain or zonal controller architectures, where a single high-performance computer can potentially replace many ECUs. For ACES ALM, this trend requires integrated design, development and test of several functions – potentially running concurrently with real-time constraints – with related signals, pins, protocols, sensors and actuators. Domain-controller architectures can also lead to the design of custom chips in order to optimize performance per watt and deal with shortages on standard chips (example: Tesla FSD Chip for “full self-driving”), i.e. require PCB design capabilities.
Integrated enterprise & embedded IT. Modern cars are connected to an OEM backend and potentially several clouds for functions such as infotainment, navigation, emergency services or over-the-air updates. The user experience depends on an integrated system from the human-machine interface (HMI) in the car over the connectivity to the backend implementation of the service in the enterprise IT.
ACES ALM needs to support integrated development of embedded software with related enterprise IT, e.g. by providing development environments with relevant development instances and test data of the enterprise backends.
Data-driven engineering. Modern automotive functions such as Advanced Driver Assistance Systems (ADAS) use machine learning, e.g. for image recognition and the interpretation of scenarios. At the same time, cars are expected to provide sensor data in order to feed the enterprise processes and also various data-driven business models (e.g. real-time traffic information). Tesla’s cars are constantly providing data on usage patterns, issues, preferences etc. Analytics is then applied to direct and prioritize the agile work within the company.
The ACES ALM environment must support this “big loop” of data collection / ingest, storage and management in the Petabyte range as well as the application of AI tools for the data scientists working on analytics, learning, development and re-integration into the car.
Processes and Methods
The growing importance and complexity of ACES software requires disciplined software engineering and configuration management practices as well as their integration into the existing product development process, for example using a model-based systems engineering approach. (Scaled) agile practices might need to be integrated into the traditional phase-gate PDP.
Model-based systems engineering (MBSE). The model-based paradigm (as in model-based systems engineering; MBSE) is becoming increasingly popular as growing complexity requires additional levels of abstraction.
In ACES ALM, this means e.g. code generation from models such as MATLAB Simulink or SysML. These models need to be managed including trace links to requirements and generated code. To realize the full benefits of this approach, the models should be executable for simulation in the verification and validation processes and integrated into the test automation toolchain.
Process and tool baselines. Especially for ADAS functions, the product liability risks for automotive companies are very high. One approach for risk mitigation is the ability to reproduce the used development practices for a given point in time, i.e. the ACES ALM environment should be able to persist baselines of a configuration of processes, methods and tools.
Variant and configuration management and Product Line Engineering. Managing various versions, branches and builds for different OS platforms is a core function of traditional ALM.
ACES ALM also needs to manage code / parameters with respect to the vehicle configurations, including compatibility management as described in the discussion of “software update management”. A vehicle configuration might be determined by model, drive, extras, production site, target country etc.
ISO 26580 focuses on feature-based Systems and Software Product Line Engineering (PLE) as a specialization of general PLE according to ISO 26550. Both documents describe concepts, methods and tools to increase re-use of engineering artifacts across variants.
Scaled Agile. The complexity of automotive applications such as automated driving and connected services requires large teams of a few hundred to a few thousand people. Scaled agile frameworks such as SAFe support the scaling of basic agile principles to this size. Especially the project management and team collaboration modules in ACES ALM must support scaled agile methods.
Regulatory requirements
Many regulations need to be considered for the development of ACES software. These include, for example, Automotive SPICE, UNECE SUMS & CSMS and ISO 26262 Functional Safety. At the same time, new regulatory requirements are also emerging. Meeting these regulatory requirements is critical for the type approval process (homologation), i.e. there are potentially different regulations for each market such as EU, China, US.
The ACES ALM environment needs to ensure the reliable provision of all current, relevant requirements for a given development scope. It further needs to support the traceable implementation and validation of these requirements and maintain an audit trail.
To support assessments or audits, an explicit process model with linked work products for each activity is desirable. Workflow management features make the process model executable, thus ensuring compliance.
Automotive SPICE. ASPICE maturity level 2+ has been required by OEMs for supplier qualification for a long time. By entering the field of software development themselves, ASPICE becomes an important tool for process quality also for OEMs. Explicit modeling of the processes as well as tools that produce and manage the required work products help during an assessment.
The ACES ALM environment also needs to support the vertical and horizontal traceability requirements of ASPICE, i.e. bidirectional traceability and consistency between requirements, design, code, tests etc.
Lifecycle management / Software Update Management. Customers expect state-of-the-art infotainment functions in a car as well as constant fixing of bugs and security improvements. While software can change every month, the hardware in the car has a life cycle of over 10 years and a development process of over 3 years on top of that. OEMs need to manage these different lifecycles, but they also want to enable new business models based on software-defined functions and meet regulatory requirements for type approval such as UNECE R156 SUMS (SW Update Management System) and the upcoming ISO 24089 for SW Update Engineering. For this, OEM’s need the ability to update the embedded software in the after-sales phase – ideally “over the air” (OTA) without having to call drivers into the workshop at great expense.
The ACES ALM environment needs to support the secure distribution and installation of updates in the car. This process needs to deal with compatibility of the SW update with related hardware and software in the car. For UNECE SUMS, the mapping between SW IDs and Regulation IDs is required (e.g. in the form of the so-called RxSWIN ID).
Cybersecurity. Modern connected cars have several new potential security vulnerabilities, e.g. through USB, WIFI, Bluetooth and the OTA update process. The UNECE R155 CSMS regulation requires setting-up a Cybersecurity Management System with risk management to be established throughout development, production and operations (-> (virtual) Security Operations Center SOC). With ASPICE CS, there is an extension of ASPICE for cybersecurity available. Another relevant standard in this area is ISO/SAE 21434 „Road vehicles – Cybersecurity engineering”.
The ACES ALM environment needs to support the risk identification and assessment as well as traceability to related mitigation activities. It also needs to support implementation of secure coding guidelines and security testing incl. penetration tests according to the security concepts defined within the organization.
Functional Safety. ISO 26262 is a standard for safety-critical electrical / electronic systems in vehicles. It requires a comprehensive lifecycle and quality management. Some of the requirements are similar to Automotive SPICE, but the scope of ISO 26262 also includes production and operations and the rigidity of the requirements depend on the ASIL (Automotive Safety Integrity Level).
The ACES ALM environment needs to support the execution of ISO 26262-specific processes such as HARA (Hazard Analysis and Risk Assessment) and FMEA (Failure Mode and Effects Analysis) and the creation of related information / documents depending on the ASIL. The tools and toolchains also need to be certified regarding “fitness for purpose”.
IT strategy drivers
With embedded software becoming connected and data-driven, general IT trends such as cloud and AI apply in our field of ACES software. The IT strategy transforms these trends not only for enterprise IT, but increasingly also for the ACES IT.
Cloud-native architectures. Cloud-native is not a new or ACES-specific driver for ALM, but it is amplified through connected vehicles which are constantly sending and receiving data. This requires scalability and connectivity that is best provided with cloud-native architectures.
The ACES ALM environment needs to support efficient development in the cloud-native architecture. This might not be the case with traditional toolchains, which are targeted towards platforms such as Linux or Windows.
Developer experience. Embedded software development is tough: developers must deal with Assembler or C code under real-time constraints, limited computing resources and overwhelming regulatory requirements, but at the same time are expected to implement data-driven cloud-native architectures.
Given the scarcity of talent, the ACES ALM environment should guide developers through the processes and provide integrated toolchains with automation applied where possible.
This concludes the overview on drivers of ACES ALM. The next article in this series will identify the business capabilities that are required to deal with these drivers. Stay tuned!
Note: this is a cross-post from my LinkedIn article
