FutureMotiv Embedded System Design

…using a robust, time-resource efficient process

Writing software is easy! Writing good software is very hard, especially for functions that have a safety impact!

In order to overcome the difficulty of writing reliable, robust safety critical software it is necessary to have a structured methodology and a structured architecture into which the function can be implemented. FutureMotiv has developed a series of pragmatic processes and a robust architecture for safety critical function implementation.

Some classical solutions to the problem of creating these complex systems involves layer upon layer of overly bureaucratic procedures and the adoption of software architectures that carry a lot of excessive baggage with them.

With our partners we have negotiated these challenges by having a pragmatic, time efficient implementation of ASPICE. We also use robust but light versions of operating systems with model-based development techniques. This allows us to deliver robust solutions following the concepts of ISO26262 in a timely manner.

VCU Software Architecture: A Structured Approach for AUTOSAR and Non-AUTOSAR Environments

Automotive software development demands a structured approach to ensure scalability, reliability, and compliance with industry standards. One widely adopted framework is AUTOSAR (Automotive Open System Architecture), which standardizes software architecture across ECUs while allowing flexibility in application layer design. AUTOSAR is a robust solution but comes with a high demand for CPU resources.

This article presents a VCU Software Architecture that can be implemented independently into an architecture similar to an AUTOSAR-compliant system. While AUTOSAR primarily defines vehicle-wide standardization, the application layer within an ECU can still follow various architectures, including the one outlined below.

Whether operating within an AUTOSAR environment or as a standalone embedded solution, this approach ensures structured software development for VCU applications. The notes below illustrate how the FutureMotiv model can take a classical architecture and implement this in a structured but resource efficient manner.

Core Software Layers
The VCU software architecture consists of five functional blocks: IP (Inputs), IPP (Input Processing), APP (Application), OPP (Output Processing), and OP (Outputs). These ensure a structured flow from sensor data acquisition to actuator control.

1. Inputs (IP)
   This layer collects data from sensors and other systems via:
   • Automotive communication protocols (CAN, LIN, Ethernet).
   • Analog and digital signal inputs from vehicle sensors.
   In the FM model: Inputs typically interact with the Communication Stack, including the PDU Router and COM module, ensuring standardized message handling.
2. Input Processing (IPP)
   Processes raw sensor data for use in the application layer by:
   • Converting values to SI units.
   • Filtering and signal conditioning.
   • Signal recombination and pre-processing for use in higher application layers.
   In the FM model: This processing can be implemented in Complex Device Drivers (CDD) or Software Components (SWCs) within the Application Layer.
3. Application (APP)
   The core logic resides here, implementing:
   • Powertrain and chassis control (e.g., torque management, braking, energy efficiency optimization).
   • Advanced Driver Assistance Systems (ADAS) algorithms.
   • State estimation and real-time decision-making.
   In the FM model: Application logic is structured as SWCs, interacting via the Runtime Environment (RTE) with both the underlying software stack and other application components.
4. Output Processing (OPP)
   Prepares control signals for actuators and other external components by:
   • Scaling and conditioning outputs.
   • Applying safety mechanisms.
   • Ensuring compliance with physical hardware requirements.
   In the FM model: This stage can also be implemented using SWCs, ensuring that actuator commands follow standardized output processing flows.
5. Outputs (OP)
   The final layer drives load and transmits data to external systems through:
   • CAN, LIN, Ethernet, Analog, and Digital outputs.
   • Direct actuator control (e.g., motor control, throttle regulation).
   In the FM model: Actuator control is commonly interfaced with the I/O Hardware Abstraction (I/O HW Abstraction) and Complex Drivers.

Advanced Layers for Robustness
Beyond core functionality, two essential layers enhance system robustness: Diagnostics and Safety.

Conclusion

The described VCU software architecture provides a structured approach that can be implemented in both AUTOSAR-compliant and non-AUTOSAR environments. By integrating standardized communication, diagnostics, and safety mechanisms, teams can develop scalable, maintainable, and robust automotive control software.

This architecture remains flexible, allowing teams to adapt their implementations based on specific requirements, project constraints, and regulatory standards. Non-AUTOSAR solutions are fully viable for applications where lighter, custom-tailored software solutions are needed that are required to be delivered in a time efficient manner.

Understanding different approaches helps software teams design optimal VCU architectures that balance complexity, compliance, and performance. When designing a custom embedded control solution, selecting the right software framework is key to achieving functional safety and efficient vehicle control.

Let’s discuss how you can benefit from our engineering expertise, taking you from concept to production. Whether you want a full vehicle solution or want a specific software layer to be developed, we are here to make it happen.