Category Archives: Others

Integration of SAE J1939 stack with an Android Infotainment system | In-vehicle ECU communication

As a trusted embedded technology partner, we at Embitel Technologies have delivered an end-to-end automotive infotainment solution for a Tier-I Supplier.

Now under production, this system will be deployed for commercial vehicles.

Business Challenge:

The infotainment system is loaded with information and entertainment related multimedia features like virtual gauges, navigation maps, voice recognition, access to media files, app-store, phone call/message syncing using BT and more.

Hence this system needs to communicate with several ECUs to fetch various vehicle parameters.

Embitel’s infotainment software development team needed an off-the-shelf communication layer that can be configured easily. This would ensure reduced development time and add value to the bottomline of the project costs.

Embitel Solution: in-house designed reusable J1939 stack with provisions for faster configuration

The team decided to integrate the J1939 stack designed in-house to save time and costs. So our cross-functional expertise in Embedded and Automotive technology added value to our client’s product roadmap.

Following are the details of the solution:

• Re-usable SAE J1939-compliant stack best suited for commercial vehicles was integrated with the Android OS
• The ported J1939 stack consisted of J1939 Data Link and Transport Layer (J1939\21), Network Management layer (J1939/81) and Vehicle Application Layer(J1939/71)
• 50 PGNs were easily configured only in the Application layer, rest of the stack was integrated as it is
• SAE J1939 compliant Boot Loader was also ported to facilitate eprogramming of ECUs efficiently and securely via CAN network
• All this ensured support for vehicle communication and reprogramming of ECUs
• All the necessary device drivers were designed, developed and ported by Embitel
• J1939 stack has been coded as per the MISRA (Motor Industry Software Reliability Association) -C guidelines to ensure code safety, security, portability and reliability for embedded Infotainment system and applications
• J1939 stack also ensured Enhanced Portability for the entire system (Support for 8, 16 and 32 bit Embedded Controllers)

Embitel Impact:

• Reduced development time and costs as the readily available and re-usable J1939 stack was integrated
• Since PGN configuration was required to be done only at the Application Layer, it ensured added time advantage
• Cross-functional teams with complementary skill-sets delivered a timely value-add to the overall cost and quality to the infotainment project

What is an Infotainment System?

Infotainment in automobiles is the integrated system that delivers entertainment and information content.

Typical tasks that can be performed with an in-vehicle infotainment system include managing and playing audio content, utilizing navigation for driving, delivering rear-seat entertainment such as movies, games, social networking, etc., listening to incoming and sending outgoing SMS text messages, making phone calls, and accessing Internet-enabled or smartphone-enabled content such as traffic conditions, sports scores and weather forecasts.

Source – Webopedia

ADAS – Forward Collision Warning System

Business case brief:

Model development for FCW system

• Design using Simulink environment
• Time to contact (TTC) method to trigger forward collision warning
• Followed MAAB guidelines for modeling

Business case details:

• Code generation
• Verification & validation
• Standard QA practices to ensure quality of deliverables
• Standard Testing practices including Unit testing, Functional testing, System testing etc
• The tool Reactis to do the unit testing and open-loop MIL testing of the controller

Tool chain:

• SIMULINK and STATEFLOW
• Reactis

TEST VECTOR WRAPPER FOR LTE-PHY TEST BED

Porting Embedded Software

At embitel, we have extensive experience in embedded software posting to various flavors controller architectures and platforms. We offer complete software stack porting and last mile services for software porting requirements.

Objectives of Porting

A porting project has one for combination of following objective:

• Migration of software stack to a different processor architecture
• Migration of software stack to a different operating system
• Migration of software to a different technology platform

Requirements for Porting

To begin with any porting project, we would normally require all the available documentation and source code. For example:

• Original design document, interface documents, test specifications
• Details of tool chain used for source system
• Details of tool chain of target system if already identified

In case the current system under port does not have sufficient documentation, we would start the porting activity with preparation of code flow diagram, interface diagram and hardware and software integration documents.

3P Framework for Porting

We follow 3P strategy (three phases) with distinct objective at every phase:

1.    Feasibility analysis phase
2.    Implementation phase
3.    Testing and validation phase

The objective in feasibility analysis phase is to bring out all dependencies and detailed statement of work. This phase also helps in verifying suitability of target system for software stack under port.

The objective in Implementation phase is to progress as per outlines tasks in statement of work. The involved detailed design study, source code walk through, tracing portable and not portable code, looking for performance optimization issues, HW and SW integration requirement, communication channel requirements, and operating system and hardware abstraction layers and re-writing of non-portable code.

The Testing and validation phase starts in parallel to porting phase and ends after the porting phase. During this period, the test strategy is decided. All test plans, test data, test code are written in this phase. The basic objective of testing are to ensure that software functionality of the system is not after porting to new target system and also to ensure performance requirements.

Feasibility Analysis Phase

We do a feasibility study to ensure porting objective and features of existing system.

The feasibility phase includes following decision point:

• Understanding the source system

This includes studying the original design documentation or user documentation to know about the s/w functionality and behavior in details. If the supporting documents are not available, knowledge transfer from customer is expected.

• Deciding Target Development Tools

Deciding upon the suitable target development tools can be a critical step for simplifying the task of porting. These are finalized with mutual discussions with customer.

• Deciding About Porting Strategies

Porting strategy includes identification of portable and non-portable code. Non-portable architectural differences include moving among 8-, 16-, and 32-bit architectures; support for different controllers and peripherals etc

• Testing strategy

Before starting the port, we determine what test cases and procedures are in place or need to be developed. Possibility to apply the test vectors and measure the results on both the source and the destination systems for comparison are also ensured.
 

Implementation Phase

The implementation strategy varies based on the porting objective. The strategy followed here is “A step at a time” that is to get the basic main framework of the software stack, with bare minimum functionalities, on the target platform, at the earliest.

A typical work-flow for migration to new processor architecture is,

• Get the OS up and running on the target hardware.
• Port the Hardware and operating system abstraction layer
  
• Port all required component driver, protocol stacks etc
  
• Port the application software module by module
  
• After a functional port is ready, optimize the software modules
  
• Do a system validation against predefined system vectors
  
• Complete the process by updating relevant documentation

Testing and Validation Phase

We perform standard Quality assurance practices to ensure quality of deliverables.

Our Testing Strategy Includes:

• Automated testing – Code coverage, memory leak detection, performance profiling and UML tracing
• Unit testing – Module level testing to validate individual units of code
• Functional testing – Validation against functional requirements
• System testing – Verification of total software system for all of its functional, quality attribute and operational requirements

eCall – Emergency Call System

eCall is a project intended to bring rapid assistance to motorists involved in a collision anywhere in the European Union. In case of a crash, an eCall-equipped car automatically calls the nearest emergency centre.

Even if no passenger is able to speak, e.g. due to injuries, a ‘Minimum Set of Data’ is sent, which includes the exact location of the crash site. Shortly after the accident, emergency services therefore know that there has been an accident, and where exactly.

Embitel, along with a silicon vendor, has created an evaluation platform to demonstrate eCall functionality. The chipset offered by the silicon vendor, which combines GPS and ARM core is used to create the proof of concept system.

System Overview:

• eCall is an emergency call either generated  manually by vehicle occupants or automatically via activation of in-vehicle sensors when an accident occurs.
• When activated, the in-vehicle eCall system establishes a 112-voice connection directly with the relevant PSAP (Public Safety Answering Point).
• A minimum set of data (MSD) – including key information about the accident such as time, location and vehicle description – is sent to the PSAP operator
• Embedded solution with in-built network access device(NAD)
• SIM support
• Backup power supply
• Proof of concept in partnership with a Bangalore based silicon manufacturer