Automotive Embedded Software Takes Center Stage
This is part four of a seven-part series on the growing importance of automotive software. Click here to read part one. You can also download our whitepaper, or visit siemens.com/aes to learn more.
Automotive embedded software has become critical to the functionality, desirability, and performance of modern vehicles. Software plays a key role in providing users with intuitive and exciting experiences while also improving vehicle efficiency, performance, and safety. Everything from navigation and infotainment systems to advanced driver assistance systems (ADAS) relies on embedded software applications.
The broader trends of vehicle electrification, connectivity, autonomy, and shared mobility will drive additional changes in the automotive embedded software landscape. Vehicle software features will integrate with cloud-based capabilities to enhance passenger and service-oriented features. Furthermore, electrical and electronic (E/E) architectures are centralizing and becoming modular while software features and functionality are being standardized across OEM product lines.
To keep up with these new technologies and organizational structures, as well as functional safety standards such as ISO 26262, existing development processes and methodologies are rapidly evolving. In this blog, we will discuss the process evolutions that OEMs are undertaking at a high level to keep pace with a changing automotive landscape.
Automotive embedded software development is an intricate process involving multiple domains, such as mechanical, electrical and electronics (E/E), and software, across several organizations, including powertrain, chassis, body, E/E, IT, research, and advanced-engineering. Each of these domains and organizations work together to develop a comprehensive set of vehicle platform features (figure 1). But, the increasing complexity of automotive embedded software places additional pressure on the ability of cross-organizational and cross-domain teams to effectively collaborate at a grass-roots level. These interactions, and the massive amount of resulting data artifacts, need to be managed across the development lifecycle. Accurate and clear engineering data must be available to the relevant teams as needed to ensure the coverage of the functional definition and the quality of information.
Additionally, software and vehicle development teams operate on different cadences. OEMs usually use vehicle milestones to track overall system-level vehicle features, changes, and updates. Meanwhile, software development is accomplished through fast-paced AGILE or hybrid AGILE flows. The discrepancy between these development methodologies can create checkpoint issues that hinder progress. For example, the software teams may have to wait for system-level updates that may not be ready for general consumption until the next milestone. Likewise, software teams may be under pressure to produce a software build for the next milestone, compromising quality to meet a deadline.
The conflicting development methodologies between software and product teams cause additional challenges. Tracing and visibility of information from application to system-level is much more difficult as software continuously grows in complexity. As hardware and software mature at different rates, assessing the completeness of software applications, and features, and their compatibility with vehicle systems becomes very difficult.
Feature-Centric Application Development
OEMs and suppliers realize that vehicle margins are tightening due to market disruptions and tough competition. This trend is placing greater attention on the engineering of vehicle features, especially those that are driven by software. Software-driven features are becoming a central theme of vehicle development, as these features increasingly provide the exciting capabilities (the “wow factor”) needed for vehicle differentiation. Furthermore, software features can be updated more frequently, improving or fortifying a vehicle’s attractiveness in a crowded market.
Vehicle-level software feature requirements evolve at the vehicle or platform-level interactions. Embedded software applications then realize these features by calling on an array of vehicle functions implemented over a number of computing units, sensors and actuators.
Original equipment manufacturers (OEMs) typically deal with the entire vehicle-level software feature development. Each OEM defines features and functions a little differently, so there is no hard guideline on what constitutes a feature versus a function. In general, a vehicle level software feature is either something that the customer interacts with (steering, climate-control, infotainment), or it is a high-level vehicle engineering needs such as torque management, battery-management, or other capabilities. A feature is composed of dozens of functions, while software functions are combined to implement embedded software applications. It is critical that OEMs facilitate functional reuse, redundancy, and variance across organizational boundaries, although this is much easier said than done.
OEMs are vertically integrating with in-house teams developing their own software, while suppliers compete to deliver innovation to support the required feature set. Throughout this process, OEMs must manage the engineering content for each feature. This includes ensuring that unique functionality is created as necessary, common or reusable functionality is leveraged, the variance of functional implementations is captured, dependencies of functional inputs and outputs are understood, and that the feature compatibility with vehicle-program needs is validated.
To complicate the implementation and operation of vehicle features, each application development team usually is responsible only for their own functional content, and not the overall feature(s). As a result, engineering organizations at both suppliers and OEMS tend to take an ECU (hardware) centric approach – focusing less on the feature that is being implemented.
In such approaches, it is very challenging and time-consuming to continuously verify and validate (V&V) the vehicle feature as various software and hardware components separately reach maturity. As a result, OEMs are attempting to disengage the dependence of functions to specific ECU hardware. Consequently, ECUs become computing abstractions (much like a cell phone) on which various software apps can be hosted. These computing abstractions can communicate over an underlying communication layer optimized for these computing units and cloud interactions.
A software feature-centric, architecture-driven approach can help organize the chaos of automotive embedded software development and enable rapid innovation. This approach allows systems engineers to focus on defining and managing the functional decomposition of software features and allocating, re-using, and standardizing software components to logical electrical components like ECUs (or their abstractions), sensors, actuators, and more. As vehicle programs ramp up, existing relationships between software functions and logical electrical components will identify each of the electrical components that are necessary for each feature targeted for the vehicle-program. Logical electrical components can then be assigned their physical part-numbers, tracked within the particular vehicle program, providing end-to-end traceability of how the software features are engineered and used by each vehicle program.
A Unified Platform for Automotive Embedded Software Development
Effectively implementing a feature-centric, architecture-driven approach provides a robust, secure, and widely accessible structured methodology to design, create, track and improve the complex software features that are distributed across a multitude of in-vehicle ECU abstractions, and often sourced from many suppliers across the globe. Constructing a holistic picture of the status and completeness of these many applications is critical to delivering high-quality, safe embedded software on time. From the bottom-up perspective of embedded software application development, keeping track of the feature-level context, and overall system constraints, is an absolute necessity.
Achieving such a methodology requires a unified platform for embedded software development to coordinate all the activities across a diverse tool-set to deliver a fully verified and validated build under hardware and system configuration constraints (figure 2). With such a platform, OEMs and suppliers can consolidate data-flows across the tool-chain eco-system and synergize to optimize process, methods, and tools integrations.
This unified platform, based on Polarion®, orchestrates all activities across the embedded software application definition, planning, development, quality-assurance, and delivery lifecycle. The platform can connect with varied toolsets to facilitate organic collaboration among many engineers and ensure traceability while promoting data re-use.
To continue reading on this topic, please download our whitepaper Creating a Unified Platform for Automotive Embedded Application Development. In parts five, six and seven of this blog series, we will look at the three main sub-processes of automotive embedded application development. As we explore each of these sub-processes, we will highlight key challenges and pain-points, and discuss how a unified software development platform can help address these concerns.
To learn how a unified application development platform can help companies meet functional safety standards, like ISO 26262, please register for our upcoming webinar, Increase automotive functional safety with ISO 26262 compliance.
About the Author
Piyush Karkare is the Director of Global Automotive Industry Solutions at Siemens Digital Industries Software. Over a 25 year career, Piyush has a proven history of improving product development & engineering processes in the electrical and in-vehicle software domains. His specialties include integrating processes, methods, and tools as well as mentoring product development teams, determining product strategy, and facilitating innovation.
