Siemens Digital Industries Software Capital Software Designer Applying an architecture-driven approach to onboard software design Executive summary Are you struggling with increasing onboard software volume and quality, a large number of variants and time-to-market pressure? This white paper reviews market trends that are transforming embedded software development in the automotive industry from an activity owned mostly by suppliers to a shared responsibility between original equipment manufacturers (OEMs) and suppliers. This digital transformation requires different processes and dedicated process support tooling. This white paper describes the digital transforma- tion challenge and suggests an architecture-driven approach for onboard software design based on the functionality of Capital Software Designer. siemens.com/swdesigner White paper | Capital Software Designer Abstract By 2020, the digital 200+ new electric and 10 million (semi) autono- $1.5 trillion in revenue 56% of new car buyers unitverse will reach 44 hybrid vehicle modles in mous cars on the road by from mobility and connec- would switch to a different zettabytes – a 10-fold the next three years 2020 tivity services by 2030 brand to get the technol- increase from 2013 ogy and feature the want Impact on Impact on Impact on Impact on Impact on All industries Mobility industry Automotive industry Automotive industry Automotive industry Source: IDC Source: Bloomberg Source: BI Intelligence Source: McKinsey and Company Source: Strategy& Figure 1: Megatrends transforming the automotive industry. The market trends in the automotive industry point manufacturers are using software to take more respon- towards connected, increasingly autonomous, highly sibility for the driving process. Classically clear-cut customized, electric and networked vehicles that are boundaries between infotainment and vehicle operat- perceived by younger generations more as “tablets on ing are blurring. wheels” than as traditional vehicles. These vehicles are Consequently, a collection of completely new functions expected to be extensible over their life through app increases the volume of onboard software by orders of purchases and installations, and offer passengers magnitude. A large portion of this software is critical for added-value services that are based on networks (see safety. Connecting vehicles to the internet opens it up figure 1). In addition, time-to-market pressure keeps to security threats, compromising vehicle integrity and building, and product complexity frequently leads to passenger confidentiality and safety. Due to constraints defects that aren’t detected until late in the process regarding weight, power, heat transfer and cabin space, when they are more expensive to fix, thus diminishing it is not possible to continue adding functions by adding the company’s profit. more electronic control units (ECUs). Thus, the industry Although software was used to run subordinate, low- will see a consolidation of software functions for large, level embedded control and entertainment functions in multi-core ECUs. As specified by AUTOSAR, dynamic the past, today it is used to: perceive and categorize its updates and extensions require a departure from static environment, coordinate the driving process in ECU images. Instead, manufacturers will need to move advanced driver assistance functions, provide telemetry toward a dynamic architecture more resembling gen- data to its manufacturer, receive over-the-air updates, eral-purpose information technology (IT) systems, as and obtain high levels of authority over route planning, specified by AUTOSAR Adaptive1. engine, gears, brakes and steering. In other words, White paper | Capital Software Designer specifications and acceptance criteria to suppliers; select and configure basic software layers, and sched- Speed Variability ule, integrate, build, verify, validate and qualify deliv- ered source code on a large scale. Since supporting the interaction with suppliers becomes tighter in the grey- Volume Quality box acquisition paradigm, the aerospace industry refers to it as the extended enterprise2. Adoption of this para- digm in the automotive industry is well documented in the contemporary literature3. Challenges in embedded automotive software. Developing onboard software in the extended enter- prise requires adequate tool support for connecting to typical application lifecycle management (ALM) systems Black-box paradigm such as Polarion ALM™ software. The same is true for: This trend contradicts the traditional approach in which most embedded onboard software has been developed • Connecting software variability to the product lines and integrated by suppliers into components or subsys- • Specifying systems and software requirements, tems. Acquiring and integrating engines, gearboxes, functionality and quality of service heating, ventilation and air conditioning (HVAC) sys- tems, seats and lighting systems are examples of such • Describing software architecture and its needed black-box systems. Integration happens simultaneously functional and timing properties in multiple domains, such as mechanics, thermal, • Creating supplier design specifications and integrating hydraulics, electrical, electromagnetic interference and delivered software artifacts buses. In this paradigm, embedded software is shipped • Verifying software compliance with specified as a nearly invisible part of the supplied subsystem, and properties it is not supposed to be frequently updated. Onboard software in this paradigm interacts with other onboard • Validating the software in its operational context software using well-defined, controlled bus signals. The • Qualifying software for production use black-box paradigm has allowed OEMs to focus on defining bus segments, packages and signals, but has • Reporting all results to the connected ALM system also led to a proliferation of ECUs in vehicles, creating Finally, large legacy code bases containing a company’s problems in terms of weight, consumed cabinet vol- valuable experience needs to be considered, as few ume, heat and power consumption. projects are start from scratch. Gray-box paradigm A gearbox designed by a supplier will deliver its soft- ware not as a dedicated embedded control unit, but as a binary executable the OEMs will integrate into a large- Digital transformation Adopting digitalization has enabled companies to scale ECU. This change in technology has a strong migrate existing and well-established processes from impact on the process organization between OEMs and paper-based artifacts to digital artifacts running on IT suppliers. OEMs are suddenly required to specify, order, infrastructure without changing processes. Digitalization integrate and validate software they had previously not has brought added value since with digital artifacts it is seen. This a gray-box paradigm, as the OEM will typi- easier to identify versions, re-vise, archive and search cally not develop the implementations. This process compared to paper artifacts. To a large extent, digitaliza- change is an example of digital transformation, as tion has preserved the relationships between product opposed to digitalization; see the inset box on the right. designers, manufacturers and their suppliers. Digital transformation is about realizing all the opportunities Migrating towards the gray-box approach requires digital technologies have to offer, including processes OEMs to take ownership of software requirements and and business models4. define software architectures, timing and memory needs; provide unambiguous implementation White paper | Capital Software Designer Architecture-driven design Automotive SPICE process reference model SWE.1 SWE.6 Software requirements Software qualification tests analysis SWE.2 SWE.5 Software architecture design Software integration and integration tests SWE.3 SWE.4 External development Integration and V&V Software detailed design and Software unit verifications units construction Figure 2: Key software engineering process groups of the Automotive SPICE model. Using Capital Software Designer enables you to defuse Capital Software Designer is focused on processes the potentially negative effects of increased software SWE.2 for software architecture design, SWE.4 for soft- volume, faster time-to-market, variant richness and ware unit verifications and SWE.5 for software integra- demand for higher quality by taking a uniquely compre- tion. It integrates with SWE.1 for software requirements hensive, architecture-driven, model-based approach to analysis and SWE.6 for software qualification tests embedded software design. It is tailored to the needs of through an integration with Polarion ALM, and with the extended enterprise, facilitating collaboration and software qualification. giving developers complete freedom of choice in their development environment. Frontloading defect detection and removal Architecture becomes useful if it is rich enough to be Enabling the extended enterprise analyzed before the first line of implementation code Capital Software Designer supports onboard software has been written to detect inconsistencies in the design. design in the extended enterprise, from software specifi- To this end, Capital Software Designer provides data cation and qualification to tightly integrated services types enriched by physical units, data-flow architecture targeting software engineering process groups of the enriched by formal contracts, and block annotations Automotive Software Process Improvement