AUTOSAR Software for an Ambient Lighting ECU and Integration of UDS Protocol Stack
About the Customer:
Our customer is a Tier 1 Supplier of Lighting Technology and one of the largest retailers of the automotive parts.
The three primary product lines of our customer include Concept Lighting, Engine Management Systems (EMS) & Electronic Control Units (ECU) for the automotive.
Our customer had embarked on the journey of developing a next-generation Automotive Ambient Lighting product for one of the OEMs’.
This product line required development of an Auxiliary Lighting Module (ALM) Control Unit (ECU).
To design and develop this ALM Control Unit (ECU), our customer was looking to partner with a Product Engineering Services provider who can offer the following expertise:
- Production-grade, ready-to-deploy and Industry-proven UDS (ISO 14230) Protocol Stack
- Expert team who can support with the customization and the integration of the UDS Protocol stack
- Expertise in Application Layer development for the Auxiliary Lighting Module ECU
- Expertise in AUTOSAR Architecture (AUTOSAR MCAL, RTE and BSW)
- In-depth understanding and product development expertise w.r.t CAN and LIN Interfaces
After the initial workshop discussions with our Software Development teams and also witnessing the demo of our production-grade UDS Protocol Stack; the customer had no hesitation in partnering with Embitel for the design and development of software for the Auxiliary Lighting Module (ALM) ECU.
Our teams had all the necessary software development (AUTOSAR) and tool-chain related experience and expertise.
Also, since we have had a successful partnership with the same customer for a Hardware Reverse Engineering Services Project in the past, the customer has had a first-hand experience of Embitel’s passion for quality delivery.
The Solution Architecture:
- Auxiliary Lighting Module or ALM is an Electronic Control Unit which is designed to control functions like the light color as well as the intensity, to turn ON/OFF the sequence of Auxiliary Lighting Units or ALUs’
- There can be multiple ALUs connected to a single ALM, as depicted in this diagram.
- Each ALU had been designed to control individual lamp assemblies of the ambient lighting system.
- Each ALU was required to communicate with the main ALM ECU through the LIN communication protocol interface.
The Solution (AUTOSAR Compliant Application Layer, Hardware Platform Software, CAN/LIN Interfaces, UDS Protocol Stack):
- Compliance with AUTOSAR Architecture was a key consideration for the customer because they wanted to develop a modular solution architecture . This ensured a lot of business value-add for the customer.
- Our expertise in the Vector Davinci toolchain made sure that we developed a robust AUTOSAR complaint Application Layer.
- Our team executed the Unit Testing of the software using Tessy environment
- Validation testing was done through CAPL Scripting. It was completely automated so as to allow us to test the responsiveness of the ambient lighting.
- Our expert team designed the Hardware Platform Software consisting of Base Software, Handlers, Low Level Drivers, and UDS based Flash Bootloader Software was reprogramming
- Our one-time licensing fee model for the production-grade UDS Protocol (ISO 14230) Software Stack, ensured that the customer enjoyed the value-adds of access to the source-code and the IP rights.
Having all required capabilities in one place in addition to having the Tessy environment ready and a strong CAPL Scripting team in-house, our team was able to deliver a quality solution to the.
We could utilize several of our reusable components (like UDS Protocol Stack, Low-Level Device Drivers) to reduce the overall time needed to complete the software development.
Tools and Technologies:
- Davinci Developer and Configuration
- Microcontroller: Renesas RH850
- Compiler: GHS
- Test Environment: Tessy
- CAPL scripting