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
