CONTEXT
The BCM (Body Control Module) is one of the most important ECUs (Electrical Control Units) in the vehicle. It receives several inputs (ignition switch, brake switch, key RF waves, etc.) and controls several outputs (brake lights, doors, etc.). Furthermore, it has a gateway role in the network of all ECUs which makes it a crucial support for all vehicle features. The software is developed following AUTOSAR architecture.
WORK
1st MISSION
KEYWORDS
- Embedded systems
- Automotive
- AUTOSAR
- Safety
- ISO26262
- Agile
- Jira
- DOORS
- C
- Bash
My first mission was in automative software functional safety following the process of ISO26262 standard. The BCM is architecturally divided in several features. Each of these features has system-level safety requirements. Starting from these, I created the documents (Software Safety Concepts) describing how a given software version implements (or does not implement) these requirements. I also ensured the global architecture traceability, from system-level safety requirements to software implementation to vehicle test specifications. I also performed Software Safety Analyses that verified if ASILs (Automotive Software Integrity Levels) were respected by the software. All these documents had to be orally presented in a review process.
2nd MISSION
KEYWORDS
- Embedded systems
- Automotive
- AUTOSAR
- Problem solving
- Testing
- Scripting
- Debugging
- CANoe
- winIDEA
- Lauterbach-Trace32
- Git
- C
- Bash
My second mission consists in global problem solving in automotive software. A constantly growing pool of Problem Reports coming either from system testing team or customer is our target. A Problem Report is basically a testing procedure in which the observed result is different from the expected result. The job was to find the root cause. It is very important to remember that a Problem Report is by no means an absolute truth, but merely a phenomenon that an entity thinks it has observed. This mindset is necessary because a bug can only be worked on after the described behavior has been reproduced. Until then, it is required to gather as much information as possible regarding the testing procedure, the requirements it was supposed to test, the environment in which the test has been made, the exact software version used, while also trying to reproduce the issue on the bench (CANoe simulator + winIDEA or Trace32 debugger). When the issue has been reproduced, true "bug" root cause investigation can begin.
The reported behaviors can be localized in any part of the AUTOSAR software stack: application, Runtime Environment, basic software (networks like CAN and LIN, non-volatile storage, mode management, real-time issues, complex functionnality like Remote Keyless Entry, etc.). As such, it is often necessary to create instrumented versions of the software that give us the opportunity to observe phenomenons inaccessible through classical means (simulator, debugger, etc.). This, in turn, requires an actionnable understanding of the software architecture.
The state of research shall be documented clearly and regularly in the Jira ticket. Depending on the ticket priority and complexity, it may also be required to speak directly with the customer.
Problem diversity requires knowledge in scripting to automate repetitive tasks.