Application Definition and Planning

This is part five 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 application development is an ever-changing and maze-like endeavour where many different tools and teams must try to collaborate under constantly shifting constraints. This environment makes cooperation a challenge, leading to problems. Today, software systems are a major source of program risk due to the complexity and criticality of software applications. As companies target connected, electric, and autonomous vehicles, the complexity of the vehicle software will only increase (figure 1). In fact, Jaguar Land Rover expects that self-driving vehicles will contain about one billion lines of code (Shale-Hester, 2019).

The key to effective application development is ensuring overall consistency and compatibility between the work that various stakeholders are performing across multiple domains and organizational structures. In this blog, part five of our series on automotive embedded software development, we will focus on the application definition and planning stage. This stage stretches over the product integration, requirements, tests & targets, and the architecture definition and modelling processes.

Application definition and planning is triggered as the feature or system-level requirements, specifications, and constraints are cascaded to the software-component-level abstraction. These requirements, specifications, and constraints convey the vehicle platform or vehicle level feature design intent relevant for the embedded application design.

Software engineers decompose the system level definition down to the application level refinements and trigger updates to the planning for the software-component-level architecture. Typically, OEMs push for software function standardization and re-use across features and vehicle platforms so that downstream software-component-level architectural considerations can be streamlined.

A major challenge is deriving the requirements, specifications, and target behaviors of the application and software functions, while maintaining a system level context. Software engineers must know how each element of the application definition ties back to the related elements of the system level features, constraints, or requirements to assess change impacts, realize innovative solutions to design problems, and more. Ambiguous, missing, or incomplete information is common and can cause lengthy delays or expensive rework downstream. This is where a unified, integrated, and extensible platform for embedded application development can deliver a considerable value-add.

Coordinating Application Definition and Planning

Advanced application development and coordination platforms can consume and track the system level product definition to create a direct link between system level changes and application development, ensuring the application and the overall system development stay in sync (figure 2).

As system engineers make tradeoffs for new and modified content at the vehicle platform level architectures, the resulting changes to requirements, models, specifications, safety goals and more at other abstractions must be cascaded appropriately to all affected stakeholders. This includes embedded software application development, which may be in process at the OEM or at multiple suppliers.

Cascading this information throughout and between organizations requires the integration of tools in a way that makes collaboration between systems engineers and application development engineers inherent to the engineering environment. This demands a platform that provides full traceability all the way upstream to the system context and downstream to models and lines of code. This enables the engineering teams to reduce the number of deviations, non-conformance, reworks, project delays, and warrantee related recalls.

​As the application-specific requirements, specifications, and behaviors are refined, an advanced application development and coordination platform will prompt software architects to optimize the software architecture by creating or updating software models and capturing interactions between software components. Such a platform orchestrates the creation and modification of these deliverables by facilitating collaboration across industry standard tools such as Embedded Software Designer (ESD), MATLAB/SIMULINK, Enterprise Architect, and others.

As the models and component interactions are developed and become mature, the application development and coordination platform can link them back to the application definition for verification and validation. This ensures that all the necessary requirements, specifications, and behaviors have a model representation with robust architecture that connects all the necessary software component interactions. ​This step validates the software model before full code is committed and implemented.

By unifying the application definition and planning stage activities with a single platform, software engineering teams can track tasks assigned or flagged as suspect (due to a change) for modeling, coding, test-execution, build production, and more across the needed toolsets. The platform allows all engineering teams to peek into the system level definitions and constraints and collaborate with other system users as changes are flagged.

Example: Implementing a System Level Change

For example, consider the implementation of a change from the system-level abstraction with a unified platform for application development and coordination (figure 3). The change combines the system-level automatic emergency braking (AEB) and adaptive cruise control (ACC) features on the adaptive cruise control module (ACCM).

The systems engineer updates the functional interaction to combine the AEB and ACC features. This update results in a new functional allocation to the logical ACCM ECU consisting of new functions. These new allocated functions have additional requirements that are now available for the ACCM software application implementation. An engineering change notice (ECN) is created from the system level in the PLM solution. The ECN propagates the change to the lead software engineer, via the embedded application engineering platform, for implementation in the ACCM software application.

Having been notified of the change, the ACCM software leadinvestigates the functional changes and reviews the added or modified functional requirements. This enables the software lead to examine the effect of the change on the software requirements. With this understanding, the software lead assigns the creation or modification of software requirements to the software engineer.

The software engineer uses the application engineering platform to review the functional changes required as a result of the added or modified functional requirements in the PLM solution. The engineer then modifies the software requirements and adds new ones to reflect the added functionality. The embedded application engineering platform provides metrics on the quality of changes to the requirements and creates links to flag suspected changes in modeling, coding, testing, and application builds as a result of the requirements changes.

The software architect is able to view the suspect links to the affected models or architectures on their home page of the application engineering platform. The architect evaluates the impact of the new requirements and resolves any suspects. The architect then modifies software architecture accordingly in ESD, and generates Simulink models for model-in-the-loop (MiL) verification. Saving the Simulink models automatically triggers an update in the embedded application engineering platform, maintaining traceability.

In this example, a system level change led to software level changes, which the application engineering platform automatically identified to the key persona: the software lead. The software lead was able to view the system level changes in the context of the software implementation, making the needed changes to the software application much clearer. As the software engineer reviews and implements the needed application requirements changes, the application engineering platform ensures the changes are completed with clarity and quality while remaining in the context of the system level changes. The embedded application development platform automatically organizes the modeling and architecture data the software architect needs to implement modeling changes and perform needed testing.

Application Definition and Planning: From Chaos to Coordination

A unified software engineering platform enables engineers to interact with the product direction and system definition. This interactivity ensures that software engineering stays consistent with the system needs and hardware constraints while they implement at the application level. Furthermore, this end-to-end traceability allows close alignment between OEM and supplier guidelines, activities, and timelines with clarity and quality. As software engineers and architects complete the application definition and planning, they can also leverage this platform to ensure consistency and make trade-off analyses across the functional architecture.

Application definition and planning is just the first step in developing the sophisticated software applications that are in high demand today. To read more about this initial step, please download our whitepaper Orchestrating Automotive Embedded Application Development: Application Definition and Planning. Part six in our series will cover application development and quality assurance, and part seven will discuss application delivery and maintenance.

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.

References

Shale-Hester, T. (2019, April 16). Driverless cars will require one billion lines of code, says JLR. Auto Express. Retrieved from https://www.autoexpress.co.uk/car-news/106617/driverless-cars-will-require-one-billion-lines-of-code-says-jlr