As vehicles evolve into software-defined vehicles (SDV), they rely on a new development paradigm in which hardware and software are decoupled. The Automotive Software Factory (SWF) supports SDV by providing the infrastructure, tools, and processes necessary to develop and deploy complex software, often within a multi-platform environment that includes AUTOSAR, Embedded Edge software, and AAOS. This setup enables rapid, reliable delivery of software updates and fosters continuous innovation.
AUTOSAR Classic and Adaptive Platforms
AUTOSAR (AUTomotive Open System ARchitecture) is a global development partnership that provides standardized architecture, interfaces, and development tools for automotive software, enabling interoperability and modularity across suppliers and OEMs. The two main AUTOSAR platforms are:
1. AUTOSAR Classic Platform
- Target: Primarily for ECUs (Electronic Control Units) managing safety-critical and time-deterministic tasks like engine control and braking.
- Architecture: Based on a layered architecture (e.g., Basic Software, Runtime Environment, Application Layer).
- Main Focus: Real-time systems with limited dynamic memory allocation.
- Software Factory Context: In an SWF, AUTOSAR Classic modules are integrated, built, and validated against requirements using CI/CD pipelines. Classic AUTOSAR ECUs are simulated on virtual ECUs (vECUs) to verify functional safety and real-time constraints before physical testing.
- Testing and Release:
- Simulators: Tools like vECU, QEMU, or specific AUTOSAR emulators.
- Hardware-in-the-Loop (HIL) Testing: Tools like dSPACE are used to simulate real-time responses for safety-critical ECUs.
2. AUTOSAR Adaptive Platform
- Target: Designed for high-performance, non-safety-critical applications, such as ADAS (Advanced Driver Assistance Systems) and infotainment.
- Architecture: Service-oriented architecture supporting dynamic memory management and multi-core processors.
- Main Focus: Flexibility, Ethernet communication, and adaptive applications that can evolve over time.
- Software Factory Context: In an SWF, the Adaptive Platform facilitates the rapid addition of new features. Adaptive AUTOSAR components are typically developed and tested in containerized environments or on the cloud for scalability.
- Testing and Release:
- Containerized Simulation: Deployed in a containerized format (e.g., Docker) for easy orchestration and testing.
- Cloud-Based Testing: Simulation on cloud infrastructures like AWS Graviton for large-scale service validation and integration testing.
Embedded Edge Software: Yocto Linux, Eclipse LEDA, and Kanto Container Orchestration
Edge computing in automotive enables processing data closer to the source, reducing latency, and enhancing real-time decision-making. An Embedded Edge Software stack based on Yocto Linux and tools like Eclipse LEDA and Kanto Container Orchestration is used to support these requirements.
1. Yocto Linux
- Purpose: Used to create custom embedded Linux distributions for automotive applications. Yocto supports high configurability and is ideal for building minimal Linux setups optimized for automotive systems.
- Software Factory Context: Yocto configurations are part of the software build pipeline, allowing for cross-compilation and testing across various hardware setups (e.g., ARM-based ECUs).
- Testing and Simulation: Yocto-based builds can be tested on virtualized setups like QEMU or cloud-based emulations, ensuring they work reliably before deployment.
2. Eclipse LEDA
- Purpose: A tool for edge device management and application lifecycle. It integrates with IoT frameworks, managing deployment, configuration, and monitoring.
- Software Factory Context: LEDA assists in orchestrating edge applications, pushing updates, and monitoring them across distributed devices, often used in conjunction with CI/CD tools for automated management.
- Containerized Applications: LEDA supports containerized application deployment (e.g., Kanto-based), providing flexibility for different types of edge applications.
3. Kanto Container Orchestration
- Purpose: Orchestrates edge applications and services within containerized environments, supporting multi-node deployment.
- Software Factory Context: In an SWF, Kanto manages and deploys containers at the edge, integrating with cloud infrastructure for remote updates and over-the-air (OTA) or firmware-over-the-air (FOTA) upgrades.
- OTA/FOTA Services: OTA/FOTA management is integrated into the factory’s pipeline, allowing edge software to be updated seamlessly, improving the user experience and minimizing in-service time.
Android Automotive Operating System (AAOS)
Android Automotive OS (AAOS) is a full-stack, open-source platform for infotainment systems, built by Google, based on Android. It enables rich user experiences through multimedia, navigation, and in-vehicle services.
Key Components of AAOS in an SWF:
- Infotainment and App Ecosystem: AAOS supports a diverse range of apps, enhancing the in-car experience with real-time data, location-based services, and media streaming.
- Customizable Framework: OEMs can customize the AAOS platform for their specific needs while leveraging Android’s extensive developer ecosystem.
- Software Factory Context: In the SWF, AAOS applications undergo a comprehensive build, simulate, test, and release cycle. Developers can create, test, and update AAOS apps via CI/CD pipelines, while containerized testing or cloud-based simulations (e.g., AWS Graviton) emulate real in-vehicle environments.
- Testing: Use of QEMU and vECU for simulating AAOS applications and system updates, facilitating pre-deployment validation and user experience refinement.
Simulation, Testing, and Release Tools for SWF and SDV
In an Automotive Software Factory, simulation and testing are fundamental to ensuring software reliability and performance. Key simulation and testing tools include:
- QEMU: A widely used open-source machine emulator and virtualizer for testing embedded systems like ECUs.
- vECU: Virtual ECUs allow for software testing independent of hardware, accelerating development and reducing dependency on physical prototypes.
- Cloud-Based Simulation (AWS Graviton): AWS Graviton-powered EC2 instances provide scalable cloud infrastructure for ARM-based simulation, essential for testing ARM-based automotive applications.
- HIL and SIL Testing: Hardware-in-the-loop (HIL) and software-in-the-loop (SIL) simulations enable realistic testing of automotive systems in the SWF, verifying integration with real hardware components when needed.
- CI/CD for Testing and Release:
- Automated Test Frameworks: Tools like Google Test, Robot Framework, and Jenkins are used for automated testing across CI/CD pipelines.
- Compliance Testing: Specialized tools (e.g., VectorCAST, Rapita Systems) ensure compliance with ISO 26262 and Automotive SPICE.
- OTA and FOTA Updates: Integrated into the CD pipeline, OTA/FOTA services allow the SWF to deliver secure, real-time updates to vehicles in the field, enabling continuous improvement and new feature rollouts.
Summary: Automotive Software Factory for SDV
The Automotive Software Factory (SWF) for Software-Defined Vehicles (SDV) leverages cutting-edge technologies like AUTOSAR Classic and Adaptive platforms, Embedded Edge Software (Yocto Linux, Eclipse LEDA, Kanto), and Android Automotive OS to build, test, and deploy software with precision. Key processes such as CI, CT, and CD, supported by cloud-based simulations (AWS Graviton), HIL/SIL testing, and OTA/FOTA services, ensure automotive software can evolve rapidly while maintaining quality and safety standards.
This integrated approach provides the flexibility to innovate and the rigor to meet compliance, ensuring that SDVs remain secure, reliable, and capable of adapting to new demands. As a result, the Automotive Software Factory represents the foundation of next-generation automotive software development, leading to faster time-to-market, enhanced customer experiences, and sustained competitiveness in the evolving automotive landscape.
No comments:
Post a Comment