Enabling a closed-loop behavioral representation of a vehicle’s software and hardware systems for continuous validation throughout the product lifecycle.
The rising intelligence and connectivity of vehicles are making the interactions between software and physical systems more complex, exposing the deficiencies of current processes, tools and methods. To compete in the technological race for the future of mobility, companies must evolve their software development processes today. A common digital thread connecting software and physical systems together is the only way to take control of the increasing complexity of smart and connected products.
This will enable a closed-loop behavioral representation of a vehicle’s software and hardware systems for continuous validation throughout the product lifecycle. A robust digital thread will help engineers ensure that software features are fully compatible with the vehicle in which they are deployed and complete with evidence showing that all related tasks and deliverables are available on time. The digital thread will also track accountability for changes regarding not just who, but how and why.
How can companies best implement such a digital thread?
Unifying automotive embedded application development
Effective automotive embedded software development requires a robust, secure, and widely accessible methodology to design, track, and improve the complex software features that are distributed across a multitude of in-vehicle ECUs and often sourced from many suppliers across the globe.
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 1). With such a platform, OEMs and suppliers can consolidate data-flows across the development eco-system and synergize to optimize processes, methods, and tool integrations.
Figure 1: A unified platform for automotive embedded software development is needed to deliver verified and validated application builds based on hardware and system constraints.
A unified platform that orchestrates all activities across the embedded software application definition, planning, development and delivery lifecycle, while also connecting with varied toolsets, will facilitate organic collaboration among many engineers, ensure traceability, and promote the re-use of available data.
Embedded application development: Three processes
The orchestration of automotive embedded software application development can be divided into three segments (Figure 2):
The key is to continuously ensure consistency and compatibility between the work that various stakeholders are performing across many platforms and organizations. A unified software development platform helps companies to orchestrate each of these processes, and the activities therein, with a single digital thread. Then, individual organizations can use AGILE or other methodologies to deliver robust embedded software applications on budget and on time.
Figure 2: The three segments of feature-centric automotive embedded application development
Application definition and planning
Polarion, as the advanced software development coordination tool, can consume and track the system-level product definition to create a direct link between system-level changes and application development, ensuring the project and the overall system stay in sync.
The system-level definitions and hardware constraints are codified into system-level requirements and specifications. Software engineers can then decompose the needed mix of hardware and software requirements, noise factors, failure modes and effects analyses (FMEAs), and more to begin embedded software application-level definitions and planning. The creation of, and any subsequent changes to, detailed software requirements will trigger software architecture and model changes.
Application development & QA
The software component architecture and modelling tasks verify and validate that component interactions achieve the desired functionality. As models become more robust and complete with verification and validation, code changes and updates can be completed and tested with software-in-the-loop (SiL) and, further down, with hardware-in-the-loop (HiL) testing. Engineers can then perform model updates and test again to ensure consistency, compatibility, and overall accountability at the vehicle feature-level.
This model-based approach not only speeds up the process but can also instill methods such as safety of the intended functionality (SOTIF), ensuring that the software is working as intended, and hazards and unintended functionality are prevented by-design. Incorporating SOTIF methods complements standard functional safety and systems theoretic process analysis (STPA) approaches that mitigate risks by employing safety goals that assume faults will occur. This combination produces exceptionally robust automotive embedded software applications.
Application delivery and monitoring
Finally, the embedded application must be delivered to the software assembly that will be included in the final vehicle bill of materials (BoM). First, engineers must prepare the application for delivery and establish infrastructure to monitor the application post-delivery. This includes constant monitoring of how and where the application is being used in the vehicle architecture.
Throughout the application development, delivery, and monitoring, the software development platform solution can connect with various tools to provide code performance, test coverage data, and to ensure alignment with methods and coding standards. The application also needs to be verified and validated with virtual and physical hardware to ensure the desired functionality is achieved and that the system will perform safely. This ensures the embedded software application is complete, compatible and meets the vehicle system-level requirements and needs.
Application compatibility, however, is shifting from being hardware-based to being determined primarily by the operating system. As a result, it is becoming very challenging to manage the compatibility between automotive embedded software applications and the embedded system-level software, underlying hardware variants, and vehicle variants (Figure 3).
Figure 3: Automotive embedded application configuration management becomes more challenging as software becomes less dependent on hardware, similar to the smartphone application ecosystem.
A robust combination of application lifecycle management (ALM) and product lifecycle management (PLM) is critical to manage this complexity. A unified hardware-software platform allows the OEM to build and support the basic processes and infrastructure for “as-designed” (for development), “as-released” (for engineering), “as-built” (for vehicle assembly plants), and “as-serviced” (for over-the-air and dealership updates) software builds.
Conclusion
Companies that are able to effectively manage the development of software applications across organizations, engineering domains, and functional abstractions will be in the best position to thrive in the digitalized automotive industry. This will be especially true as software functionality becomes less dependent on ECU hardware due to an increased use of vehicle operating systems and firmware. In this new environment, a unified and collaborative environment for SW development that builds-in traceability and IP reuse will prove invaluable.
For more information and to read an example application, download our new whitepaper: Creating a Unified Platform for Automotive Embedded Application Development.
 |
 |
 |
 |
 |
 |
Leave a Reply