Aigmented Designs Engineering & Safety Advisor: Responsible for preparing the ISO26262 & IEC61508 SW Tool Qualification, Definition of the SW Safety Development Process & tools, Specification of the High Level Requirements of the ALM covering all aspects (Connectivity, Safety Qualification, IT/IS infrastructure, Architecture, Process, Marketing, Management, Configuration, etc.)

Providing a French Start-up CEO with "Engineering & Safety Advisor" services to build an ALM dedicated to the development of safety critical mechatronics developments

- Embedded System/Software Engineering (from Management/Support to the whole System/Software lifecycle and manufacturing/series life/maintenance phases, SW Factory Automation),
- PC based SW Engineering (Agile lifecycle, Changes & Bugs Management, Build & Release process, Upgrade strategy, HMI, Qualification for safety/security applications, connectivity to other SW tools/applications, etc.)
- Functional Safety & Cybersecurity (ISO 26262, IEC 61508, ISO 21434),
- Quality Assurance & Performance Improvement (CMMI, ASPICE, ISO 15504, ISO 9001, IATF 16949...),
- Agile SCRUM and
- the related SW/HW tooling widely deployed in the industry: ALMs, Project Management tools, MBSE/MBSA/MBD tools with/without automatic code generation, IDEs, Safety & Cybersecurity Analyses tools (HARA, DFA, FMEA, FTA, TARA...), Configuration/Version/Change/Issues Management tools, Continuous Integration & Build tools, V&V Tools, Measurement Instrumentation (Oscilloscopes, Serial Data / BER Analysers, Spectrum Analysers, RF Generators, AIO/DIO boards, Multimeters, analog/digital sensors & actuators), Test Automation tools.

Documentation of:
- a High Level Requirements Specification for the SW Platform (Connectivity, Safety Qualification, IT/IS infrastructure, Architecture, Process, Marketing, Management, Configuration, etc.)
- a Safety Development Road map + interface with TÜV SÜD to prepare the safety certification TCL3/ASILD-SIL3 in compliance with the selected safety standard ISO 26262 and IEC 61508
Interface with Dassault 3DS for the evaluation of CATIA (PLM)+ Reqtify + MagicDraw (UML)

Preparation of the corporate SW Development process:
- to drive the safety/quality and "ZERO bugs" culture within the company
- to comply with safety standards and get related TCL3/ASIL D-SIL3 certificates

Manage all Quotes, Invoices, Payments tracking in dedicated state-of-the-art web-based tool (ZohoBooks) shared with client's CEO for approvals.
Manage and track to closure all tasks related to Engineering Advisor activities thanks to the web-based PM tool "ClickUp".

Regular communication with client's CEO to provide full visibility/transparency and align on short/mid/long-term objectives.

LEM TECH France Functional Safety Management, Engineering & Assessment consultant (ISO26262 ASIL B)

Considering I had no official management  responsibilties / non-exhaustive list:

• First time the FuSa team covers the mandatory “Confidence in the use of SW Tools” activities I defined, planned/monitored, redirected (see below point), partially performed from scratch to provide appointed internal Tool Assessors with guidelines/examples, only partially reviewed due to lack of time before the external assessment (Tools Usage planning, Tools Evaluation, Tools Qualification - ISO 26262 Part 8 - low progress on that topic in the overall Automotive EE/SW industry/services, even in very well-known global market leaders) and presented during 2 formal interim & final Externals ISO 26262 Functional Safety Assessments on an ASIL B Battery Sensor which has been successful. External FuSa Assessors (Exida) highlighted during the first interim assessment the fact that we were, in general, upfront about the status of this very FuSa-specific activity compared to the competitors or other main actors of the automotive industry. As stated in our Home page, it should be noted that Antoine was also responsible for the EN50128 assessment of the software tools classification/validation (T1/T2/T3) according to the EN50128 standard for the gigantic British railway project CROSSRAIL / Elizabeth Line. He also held the responsibility as Engineering & Safety Advisor for a French startup, setting up the entire safety certification roadmap in interface with the certification body TÜV SÜD for the ALM tool that this startup is about to bring to market for safety-critical mechatronic developments. Antoine, being a holder of level 1 of the TÜV SÜD CFSP certification program, is therefore compliant with regulatory and technical expertise requirements to be OUR SW Tools Qualification Assessor (up to ASILD-SIL3 / TCL3 against ISO26262, EN 50128, and IEC 50128 standards.

• First time the FuSa team covers the mandatory “Dependent Failure Analysis” activities performed from scratch using SILCal tool (ISO 26262 Part 9 - most complex and challenging pure safety requirements of this standard, IMHO, and mandatory as opposed to FMEA and FTA which are only suggested analyses to support other safety activities, like refining the HARA and DFA for example) and presented during a formal External ISO 26262 Functional Safety Assessment on an ASIL B Battery Sensor which has been successful.

• First time Confluence and Sharepoint tools are used in the FuSa/SWQA/Cybersecurity team with state of the art practices to exhaustively (no use of basic hard drive / server without real Version Mgt tool installed on it, like Tortoise SVN) and properly store/archive/retrieve, automatically handle versions, allow collaborative and simultaneous modifications and create baselines of formal work products (whether these are process or project/product-related Configuration Items) + use of advanced dynamic and asynchronous Sharepoint features to send automatic and real time notifications when specific work products under configuration have just been modified (=> ensure better CM integrity / visibility on few sensitive work products). It motivated other team members to manage their documents in Sharepoint as well.

• First time the FuSa work products include an easy-to-understand, graphical and brief textual overview of the safety critical RCD (Residual Current Detection sensor) product in English language (without the use of AI) based on documents and an informal technical presentation provided by an Innovation Expert, this brand new sensor supposed to be a SeooC (Safety Element Out Of Context) and innovative COTS (Component On The Shelves) based on the fluxgate technology (electromagnetism concept) which was one of the key products for the future international sales strategy of the company still had NO CONCRETE HIGH LEVEL DESCRIPTION of the PRODUCT in ENGLISH LANGUAGE in a half-page to properly document and communicate project work products internally, and most important, to all external Stakeholders, including current potential clients. I then witnessed several other project plans/items that reused my product overview / high-level description in English (e.g. Functional Safety Concept from Project FuSa Manager). 🙂

• First time Codebeamer ALM has been used to estimate, schedule, track and close the FuSa and QA tasks (transversal, process & project/product). I initiated these practices spontaneously, then the Line Manager decided to move the FuSa & SWQA Team Tasks plan and tracking from a basic excel sheet to Codebeamer trackers and metrics.

• One of the very first time, if not the first time, at least during my experience at LEM, that the usual “in-house” conflict between the Group Head of SW & FuSa/SWQA team staff turns in our favor: the conflict, this time, was about one of the the previous points, the ISO26262 “Confidence in the use of SW Tools”, which, as usual, and although it has already formally been presented to the SYS/SW Management and SYS/SW/HW Team, has been partially addressed in total opacity by the Group Head of SW (although we chased several times to get visibility on their capabilities to implement the process I defined, implemented on different SW tools to be assessed including CodeBeamer ALM and CodeWarrior IDE/compiler (in order to initiate the tools usage plan and evaluation phase) and presented to External FuSa Assessor as well during the first interim assessment). When I realized it, I immediately triggered a 1-to-1 meeting with him, avoiding other people to interfere with the communication, to demonstrate his approach was not traceable to the ISO 26262, or only very partially, and that some requirements had not been properly addressed or even not at all, moreover using a different process and tool (Codebeamer) than the ones presented to Exida which were documented in Confluence, much more adapted to this kind of activity, which was totally inconsistent in Codebeamer, sprayed into numerous trackers and wikis. My assets have been my fluent, almost bilingual, level in English, my natural leadership/charism (All things considered, I don't claim to have the charisma of Al Pacino or Javier Bardem), my deep & calm voice, and most important, which was never done by the other stakeholders: spend 2 hours on the night between 10pm and 12pm to document a detailed MoM, activity background, current status, and plan for the remaining 4 weeks before the final External FuSa Assessment. Consequently, the next morning at 8:30am for the preparation & Kickoff meeting, everything was set in stone in a PPT file shared with all FuSa and SW staff members, so that the Group Head of SW couldn’t impose his approach again, which has been the case for several topics, including the SW FMEA that the Group FuSa Manager wanted to handle differently.

• Improved the templates of ISO26262 Confirmation Review of the Safety Plan and performed Confirmation Reviews on the ASIL B RCD Sensor Safety Plan (Rejected) and Functional Safety Concept including safety goals (interim approval with corrective actions)

New QA Strategy establihed in Confluence tool in order to get it much more interactive => it led to a very effective and collaborative formal and informal review of this QAP:

• 71 informal review findings raised by the Project Quality, Functional Safety, System Engineer, SW Product Leader and Project Manager (using "(un)Resolved Comments" feature of Confluence tool)

• 30 formal review finding raised by the independent System/SW Quality Engineer who used the first template of Formal Work Product Review Form (see below) including automatic KPIs that I created during the first week of my contract in LEM Tech France (Pivot tables).

"Confidence in the Use of SW Tools" mandatory activities from ISO26262 (SW Tools Usage Report) managed in Confluence tool as per my decision and presentation to the external safety assessors. Not in CodeBeamer as secretly attempted by the Head of SW, which would have caused us major problems during the final assessment.

Easy-to-understand, graphical and brief textual overview of the RCD product in English language (without the use of AI) based on documents and an informal technical presentation provided by an Innovation Expert, this brand new sensor supposed to be an ISO26262 SeooC (Safety Element Out Of Context) and innovative COTS (Component On The Shelves) based on the fluxgate technology (electromagnetism concept) which was one of the key products for the future international sales strategy of the company still had NO CONCRETE HIGH LEVEL DESCRIPTION of the PRODUCT in ENGLISH LANGUAGE in a half-page to properly document and communicate project work products internally, and most important, to all external Stakeholders, including current potential clients. I then witnessed several other project plans/items that reused my product overview / high-level description in English (e.g. Functional Safety Concept from Project FuSa Manager). 🙂

DFA Report automatically generated from SILcal tool (EXIDA) and managed in configuration in SharePoint. Here you can see a reminder of the Product Architecture, 2 extracts from the DFI List (Dependent Failure Initiators) and the "Summary & Conclusion" of the DFA report. You can find the overall compliance result (5.62) in the last 2 pictures.

Performing the DFA requires both:

- a lot of coordination of the different R&D domains from System Engineering, Electronics, Software to Mechanics and Industrialization.

- a strong theoretical and practical knowledge in the specific ISO26262 requirements about DFA, in R&D and in the product on which the DFA is conducted

It is, in my humble opinion, the most difficult topic addressed by the ISO26262, and, as opposed to FTA or FMEA, it  is mandatory.

I was rewarded throughout my 2 years as a freelance engineer at LEM TECH France right from the end of the first month when my workload increased from 60% to 100% (there were 2 freelancers hired at the same time, but the other one was not retained) and being responsible, in addition to quality assurance on the RCD project, for Functional Safety on the BDM project (in particular, "Confidence in the Use of SW Tools" and "Dependent Failure Analysis", 2 subjects required by ISO26262 and not yet addressed by LEM). My freelance contracts were extended 3 times through a recruitment agency with an increase in the hourly rate at each contract renewal, and then LEM hired me for 1 year as a tier #1 supplier and increased my hourly rate by 40%. Once again, the greatest reward remains the human adventure I had in this team as you can see from the 2 reviews that Raphaël and Massimiliano have provided. With Valeo and Ausy, LEM TECH France remains one of my best professional memories.

QEV Technologies: Creation of FuSa/QA/SYS/SCRUM Department (EE/Hydrogen Powertrain Motor Control / ISO26262, ASPICE, MBSE/MBSA-SysML)

Working as a rank#1 freelance supplier without any intermediate agency.

Hired for FuSa & QA Manager role at 50% workload (approx. 20 hours a week), responsible for the implementation of the ISO 26262 within the engineering department dedicated to Automotive industry (not racing/motor sport which has a completely different culture and practices). The company was starting a new initiative which consisted in reusing their expert knowledge in the Top Level Electric Racing domain for growing a new business, the manufacturing of Hybrid Electric/Hydrogen vehicles for the mass production of street vehicles (City buses & Electric Vans).

The first week I’ve integrated the company as freelance FuSa & QA Manager, we interviewed and hired 1 Junior FuSa and CS Engineer who used to work under my supervison for 50% of his time, the other 50% being dedicated to CS activities under the supervision of the Head of SW & Controls and the CS Project Manager.

In the scope of the creation of the Engineering FuSa/QA/SYS/SCRUM Department, about 30h/week (working 30h/week for another client), I handled as best as I could (and I've been rewarded for this through 3 conract extensions and rate increases + a permanent position proposal):

- the implementation from scratch of the ISO 26262 and the safety/quality culture;

- the definition of an Engineering Process based on ASPICE/ISO 26262/Agile SCRUM/SysML and new system requirements elicitation method: Program Plan presented to and approved by Top Mgt (duration = 2 years / internal budget = approx. 900 man.days / external costs = approx. 150Keuros) - see pictures below; 

- MBSE/MBSA (Safety Analysis) using SOX tool in SysML (Block Definition Diagram for the item/system environment, Internal Block Diagram for the item/system internal architecture, Function Diagrams for the functions and malfunctions, State Machines for the operating and failsafe modes) of the different powertrain items (Motor Control, Hydrogen Mgt, Electric Power Mgt...) to generate their Item Definitions and HARAs, Application of HAZOP method (elicitation of item malfunctions). The Item Definitions were both covering ISO26262 (FuSa) and R155/6 & ISO21434 (CS) requirements as the main inputs to the web client HARA/TARA automatically importing elements defined in the MBSE/MBSA performed in the rich client

- preparing the HARAs for Powertrain items, mainly worked on "Motor Control" Item: Functions and malfunctions, effects, operational scenarii, severity, exposure, controllability (with rationales), ASIL, Safety Goals and FTTI. Knowledge collected from our external expert but also from the generic HARA etsblished by several German Tier-1 I obtained in one of my previous job (see picture below) 

- The Management of the EE system suppliers, creation of a Master DIA - Items List (see picture below).

- the "Safety Plan" drafted in an innovative way: planning & monitoring of all activities in the safety product life cycle using Tuleap ALM and its SCRUM features to break down the powertrain into Items (e.g. "Motor Control") represented by Epics and into work products (IDs, HARAs, FSCs) represented by User Stories (& tasks), themselves allocated to releases/sprints over time, and then assigned to the Junior FuSa and CS Engineer working with me, different EE/SW staff members and of course myself, as FuSa/QA/MBSE/SCRUM Manager.

- SW tooling selection supported by a multi-criteria selection matrix documented with the outcomes of the different demos / trials / meetings: ALM (TuleAp), FuSa & System Design tool (ENCO SOX), Conf/Version Management (SVN, Sharepoint, Confluence). See our Management System page where we integarted this SOX tool in our "QMS - Operation/R&D Management System" thanks to the acquisition of a free license of the full SOX workbench (MBSE/MBSA/HARA/TARA/FMEA/FTA/FMEDA tool based on SysML) on an as needed basis, official Partnership with the Managing Director of this German SW Tool Vendor ENCO SOX

- Selection of a FuSa expert to support us: RFQ doc. sent to several FuSa expert companies (LGM, IDIADA, Exida, FEV), analysis of technical-financial offers, selection matrix with several criteria (Costs, FuSa experience at OEM level and hydrogen/electric hybrid vehicles, etc.) to support decision-making with the COO, Head of Powertrain and Head of SW leading to the choice of IDIADA (I had a preference for LGM's experience).

- Planning the workshops with IDIADA FuSa expert (2h every other week), definition of the workshop agenda, moderation of the workshops, evaluation of the expert's work, distribution of the MoM and the evaluation to internal Mgt & IDIADA Stks.

- The reporting of the QA & FuSa program progress (using Tuleap ALM and Confluence tool) to all required stakeholders, in particular, a close collaboration with the Head Of Software & Controls (see his feedback below) who was my interface at QEV.

Block Definition Diagram (BDD / SysML 1.6) specifying the high-level architecture of the hybrid Electric/Hydrogen Powertrain using the SOX tool that I selected following the Tooling Evaluation phase defined in the roadmap. The main hazards and threats have been identified, and the HAZOP method has been used to define the main functions/malfunctions of the Motor Control to represent them in the Safety Concept Diagram (Diagram specific to the SOX tool). The internal architecture of the Motor Control has been detailed in an Internal Block Diagram (IBD), and the operating and failsafe modes of the motor control have been designed using State Machines. Thus, we were able to document the "Item Definition" of the Motor Control of the Powertrain with a brand new MBSE/MBSA (Model Based System Engineering / Safety Analysis) method to cover safety and cybersecurity requirements of ISO26262 and ISO21434, this work product being the main input for production of the HARA (in SOX web client) and TARA.

EN 50128 Software Safety Assessment

CROSSRAIL - ELIZABETH LINE (LONDON) - C660 Project / Communication & Control Systems

Freelance Software Safety Assessor at SIEMENS Mobility for the CROSSRAIL Project (Elizabeth Line / London) which has a station 5 min walk from my former London apartment in West London.
Remote working (Barcelona) = 80%
Onsite working (London/Ashby) = 20%
7 months + 3 months + 5 months
Established the Software Assessment Plan for a large Safety Critical Rail project. This EN50128 compliant SW Assesmant Plan has been informally checked by the Engineering Safety Manager (K. Toon, whose feedback is added below), approbed by Siemens Mobility Engineering Program Director (as you can see in the "comments" feature and cover page of the plan) and most important formally reviewed by 5 CROSSRAIL Control & Communication Project Team members who approved the SAP using the Formal Review form with the postive result "No objection (revise as indicated below)" considering the correction requested were purely admin tasks

Conducted the Assessment of the SW Tools Classification (T1, T2, T3) according to EN50128 and detected quite a lot of non-conformances, including one consiting in the fact that the used strategy was inspired by the DO330 aeronautics standard instead of the EN50128 one. I proposed a full SW Tools Classification strategy compliant with the clauses from EN50128 in order to support the correction of this major mandatory topic.

I also actively participated in the improvement of the quality of the "Agile-like" SW development lifecycle in proposing the implementation of the REAL DoD concept (Definition of Done) at User Story Level in the Product Backlog maintained in JIRA (see picture below). I strongly suggested to implement an automatic checklist in each JIRA User Story including checkpoints allowing the verification that all required product lifecycle activities have properly been done before FAT and release for production, thus significantly reducinfg the bottleneck effect of the detection of numerous bugs in the latest stages of the lifecycle causing delays and huge costs of non-quality.

Performed the EN 50128 SW Assessment:
- Planning of the SW Assessment
- Scope of the Assessment: SW Management and Organisation, SW Quality Assurance, SW Configuration Management, Traceability, Supplier Management, SW Verification, SW Validation, SW Assessment, SW Testing, Change Control, Support Tools (other processes in the scope of the ISA from the University of York).
- Off site assessment: Rating of the EN 50128 clauses using a template of EN50128 SW Safety Assessment that I created from scratch (see pictures below)
- On site assessment: 3 days (kick-off, interviews, demos, closure)
- Consolidation and Presentation of the Assessment results to the Engineering, SW, Safety and Test Management (raised 36 Non-Conformances/Opportunities for Improvement)
- Supporting the Engineering/SW Team to define and track the Corrective Action Plan until closure

Performed SW Safety Assurance reviews throughout the SW lifecycle (SW Plans, SW Requirement Traceability etc...).
Created the SW Safety Assurance Workbook that includes all Non-Conformances raised during the SW Safety Assurance activities (Reviews, Assessments) and useful automatic metrics in order to easily visualise the overall status of the NCs (Open/Closed in total, Severity of the Open NCs, Open/Closed NCs per SW Process) => see pictures below.

Conducted a Lessons Learned Analysis on the performance of the EN 50128 SW Assessment in order to improve the Software Assessment process for the future SW Assessment activities within the organisation.
Please see the feedback from my Line Manager, K. Toon, now retired, copied below for your convenience.
Concurrently to this contract, I renewed my PMP® certification (Project Management Professional) for 3 more years (August 2022).

The contracts of the whole Safety Team (all external consultants), including the Engineering Safety Manager (9 Managers/Engineers) have been ended at the beginning of the COVID crisis, although my contract had just been extended for 5 more months.

It would have been much better to use a Quality/Safety ALM like SafetyCulture presented in  our "State-of-the-art Management System" if it would have been available in the CROSSRAIL/Siemens project to perform this EN50128 SW Assessment and all other SW reviews I executed throughout the C660 SW project lifecycle. I generated a lot of documentation that I had to manage without proper Configuration/Documentation Management Tool: this is a MAJOR weakness raised in the "SW Assessment" process, see picture at the left.

Few strengths have been raised against the SW Assesment process:

We took on Antoine to specifically address software safety assurance for a large rail project. The software development was already reasonably progressed, but in need of independent software assurance and EN50128 compliance demonstration. Antoine demonstrated great ability to able join an established project (with existing working practices and procedures) and bolster the processes, plan and conduct audits and produce recommendations effectively, where others may easily have disrupted on-going work. Antoine was an effective software processes assessor and auditor. Antoine is able to progress issues effectively, with minimal supervision. Similarly, his knowledge of, and ability to pick support tools and working environment with minimal input was most welcome at such a critical stage of the project.

Kevin Toon (retired) - Engineering Safety Manager - CROSSRAIL Siemens C660 Project (Communication & Control Systems)

RENESAS Electronics Europe: Driving REE to the compliance with ISO 26262 and ASPICE

Overview

In 2014, Renesas Electronics UK was in the early phase of its journey to compliance with ISO 26262 (:2011) and ASPICE which is, with CMMI, the best approach to establish a standard Engineering QMS and System/SW/HW process required by the ISO 26262 Part 2.

Goals

• Assess the current Requirement Management, traceability & consistency process thanks to a Functional Safety Audit of an ASIL B safety critical AUTOSAR MCAL and the monthly project audits against internal QMS certified CMMI L3.

• Eliminate all errors and inconsistencies raised against the traceability process from the SW requirements to the design, code and testing work products.

• Automate the AUTOSAR MCAL SW lifecycle process as much as possible in order to make it faster and fully reliable (free of inevitable human/manual errors).

• Do not impact the existing CM process in terms of generated SW work products including their configuration/version management ensured with Tortoise SVN tool.

• Provide the SW and Verification teams with accurate metrics about the implementation and coverage rates of the SW requirements at SW Component and overall MCAL levels, with the distinction of functional, non functional and safety critical requirements, and with the automatic detection of any inconsistency between the versions of the requirements/design items/code files/test cases.

First Phase in 2014

I quickly realized via the Monthly Project Audits I used to perform against the internal QMS that the SW Traceability & Consistency process in place in the Automotive AUTOSAR safety critical MCAL projects (and Industrial projects as well) was very probably the main weakness of the organization Vs the state of the art and was not adapted anymore to handle the huge number of SW items that such products were supposed to comply with, including functional, non-functional, safety requirements and the related hundreds of downstream SW Static and Dynamic Design artifacts and test cases/scripts.

Indeed, SW requirements traceability was created and maintained at component level only (PWM, SPI, CAN, LIN, GPT etc.) through an Excel Traceability Matrix documented/updated manually for each version of the MCAL component. Consequently, there were no overall traceability/coverage metrics at full MCAL level (and BTW, at Component level neither, just a traceability table) and the manual process was inevitably introducing shortfalls and inconsistencies in the Excel traceability matrices.

The highly probable risk induced by this weak process was to develop an AUTOSAR MCAL which was not fully compliant with its input SW requirements including the safety critical ones, thus making the achievement of the required level of Functional Safety impossible and the compliance with ASPICE & CMMI not demonstrated.

Proactive, autonomous, always exceeding my roles and objectives and willing to practically improve the performance in Quality/Cost/Timing of the company activities, I decided to initiate an AUTOSAR MCAL SW Transformation project in order to both eliminate the traceability/consistency errors detected during the Project Audits and make the overall SW process much more automated, faster, fully reliable and totally transparent via the automatic generation of implementation and coverage metrics at both BSW Component and overall MCAL levels, and this, for all types and versions of the SW requirements, functional, non-functional and safety related ones, avoiding all traceability inconsistencies among the full SW lifecycle and ensuring the correct version of the requirements and static/dynamic design elements have been properly traced to the corresponding version of the source code files and the SW Test cases (so that we don’t have outdated traceability links between SW work products).

First, I needed to get the approval from the PMO/SWQA Manager who, in this case, would contracting me to spend a huge amount of time on pure Automotive SW Engineering activities, the objective being to significantly improve the quality, reliability and efficiency of the MCAL SW process in Renesas Electronics Europe and consequently reduce the existing gap between the current compliance status and the required practices from ASPICE, CMMI and ISO 26262.

Then, after approval from my Manager, I established a formal proposal (see picture below) and I performed a market analysis in terms of existing Requirement traceability tools deployed in the safety critical embedded systems industry and selected 4 tools; I already knew 2 of them, Reqtify and DOORS, and I evaluated MKS (already tested in Düsseldorf Renesas site) and Redmine (to include an open-source tool).

I established a formal tool selection matrix (see picture below) with several criteria to evaluate the different tools: Cost, User-friendly, Impact on existing process, licenses availability needs (few times a week, every day, every hour etc.), connectivity to other widely spread engineering tools like SVN etc., availability of after sales technical support, type of licenses, install process etc.

My analysis drove me to select Reqtify, not only because I witnessed its efficiency in one of my previous job, or because it is french (😉), but also because it was perfectly fitting to our needs: Reqtify does not impact your current Configuration/Version Management process, it is a smart “gateway/hub” making the link between all your existing SW work products in which you just need to tag/label the content in a standard way (requirements, static/dynamic design elements, source code, Unit/Integration test cases). Thanks to “regular expressions”, also called regex language (which is the most difficult part of the tool admin and configuration), Reqtify will parse your SW work products and will display how many requirements are not implemented in design/code and/or not covered by the SW Test cases (or any other relevant SW verification methods or rationales).

Moreover, if you define smarter tags/labels/attributes in your SW work products and configure Reqtify with more complex REGEX scripts, the tool will provide you with information about the implementation and coverage rates of your functional, non-functional and safety requirements as well as if the correct version of your artifacts has been integrated in your SW lifecycle project, e.g. if the version of a SW requirement increases, it will inform the user about the potential need to update the corresponding design elements and/or test cases for consistency purposes.

There are plenty of other possibilities to automatically generate very useful metrics depending on the Tool admin skills in the regex scripting language, that will parse all kinds of requirements attributes/properties: Requirement Source (Customer, System Eng., derived SW needs, Upstream Safety requirements, Quality, Supplier/Co-developer, Partner, HW constraint, etc.), Maturity/Status (Drafted, Ready for verification/validation review, Rejected/To be completed, Reviewed & Accepted, Obsolete, Implemented, Verified/Validated, Released…), Verification/Validation criteria and its level (Unit / Integration / Qualification Test, Safety Validation, Test HIL/SIL/MIL, Review/Inspection, etc.), assigned ASIL (N/A, QM, A, B, C, D), priority (High, Medium, Low), Complexity (High, Medium, Low), Planned/Spent effort etc…

I submitted my analysis, proposal and tool selection matrix results but unfortunately, my project has been rejected by the Automotive BU Manager in place at this time.

Second Phase in 2015

In 2015, the PMO & SWQA Department has been solicited by the Japanese headquarters to perform the first Functional Safety Audit on our Automotive activities, in particular the development and verification of safety critical AUTOSAR MCALs as SeooC (Safety element out of Context) intended to be embedded in the Renesas microcontrollers for different Automotive Tier-1 applications (e.g. HELLA Exterior Lighting Control Systems).

Though I’ve not been requested for performing this FuSa Audit, I autonomously took the decision to use the Japanese template of FuSa Audit (including ALL clauses & sub-clauses for each Part of the ISO 26262) to start evaluating the compliance with the ISO 26262 since none of my 2 colleagues were doing it although they have had the chance to attend the formal ISO 26262 training course as permanent staff (but they were pure PMO Planners with no background in SYS/SW/HW engineering) as opposed to me who just capitalized on my successful experience in CMMI L2 deployment/certification, my background in SW MBD, development in C code, testing and on the FuSa Elearning available on Renesas Intranet.

• The Fusa Audit I performed against ISO 26262 Part 2 (Management of FuSa), Part 6 (SW process), part 8 (Supporting processes) and Part 9 (ASIL decomposition and safety analyses), on an ASIL B AUTOSAR MCAL confirmed the weaknesses of the manual AUTOSAR MCAL SW process. That was a way to officially formalize this MAJOR issue.

Luckily (for me), a new Automotive BU Manager has been appointed and he immediately contacted me to ask me if I could set up a pilot project within the Automotive BU using… Reqtify tool!! I was more than happy to confirm my willingness to do it and see that my rejected proposal in 2014 was now accepted in 2015.

Also, one very important event pushed into the right direction towards ASPICE and ISO 26262 compliance:

• The External “ASPICE/ISO26262” assessment performed by our German customer HELLA with an independent and well known Lead ASPICE/Safety Assessor, Dr Richard Messnarz (Responsible for the annual EuroSPI conference) and 2 co-assessors who were Quality Managers from HELLA staff: The Lead Assessor raised 1 main strength which was my FuSa Audit and insisted on the need to quickly address its results. This helped a lot motivating the Automotive team (and its FuSa Manager) to work on the findings and opportunities for improvement I identified in my FuSa Audit.

Following both my internal audit and the external assessment, I merged all similar findings (approx. 90% were the same findings) into one set of weaknesses to address in Process Improvement workshops I scheduled, involving Automotive BU Mgt, FuSa Mgt, Quality Assurance, V&V and SW engineering representatives to plan the correction of the identified weaknesses.

Coming back to the AUTOSAR MCAL SW Transformation project, as promised to the new Automotive BU Manager, I set up an entire pilot project in Reqtify tool based on an ASIL B Autosar MCAL, including in it all SW work products generated from the project lifecycle (from SW Requirement Specification and Design to the SW Unit and Integration Test cases).

As mentioned above, the configuration of the “regex” is the most challenging part of the Tool administration: it needs to acquire a bit of knowledge about this language that is the key activity to properly parse, extract and link all requirements, design, code, test tags/labels in order to obtain the implementation and coverage rates between all artifacts.

But, with a bit of research on the internet and the support of the japanese team who also used to set up Reqtify on their projects, I’ve been able to configure the required regex scripts to demonstrate the power of the features of Reqtify tool and formally present the pilot project to about 20-30 Managers/Engineers from different BUs.

Of course, Reqtify has then been implemented on all AUTOSAR projects but I’ve also been requested for support by some managers from the Industrial BU to set up their own Reqtify project on their industrial projects since they realized how much added value it would bring to their requirement traceability and consistency with the other items of the project lifecycle, thus strengthening their developments projects in terms of product quality and process efficiency and reliability.

Conclusion

Did we achieve the goals we defined for this Transformation project within Renesas Electronics Europe?

• Assess the current AUTOSAR MCAL SW process thanks to the monthly project audits against internal QMS) and then a pertinent Functional Safety Audit of an ASIL B safety critical AUTOSAR MCAL:

  1. Monthly project audits already detected a huge risk for product quality/safety/reliability since the traceability matrices were manually documented by the SW supplier and only at BSW Component level, no matrix at overall MCAL level but the objectives of the Monthly Project Audit are much more high-level and aim at verifying an overall project and supplier management compliance with the internal QMS (used to be compliant with CMMI, thus very PM oriented).

  2. The FuSa Audit I performed confirmed the weakness of the current RM process, both for its manual documentation (inevitably introducing human errors) and its lack of visibility at overall MCAL level (just one traceability table per component without implementation/coverage metrics to make the matrix really helpful). The pertinence of this FuSa Audit (Mandatory Confirmation Measure as per ISO 26262 Part 2) has been confirmed by the External ASPICE/ISO26262 Assessor (contracted by our customer HELLA), formally (in the Assessment report) and verbally (during the ITWs and conclusion meeting) requesting Renesas team for addressing the findings raised in it.

• Eliminate all errors and inconsistencies raised against the traceability process from the SW requirements to the design, code and testing work products:

  1. All traceability issues are automatically detected and reported to the user.

• Automate the entire SW lifecycle as much as possible in order to make it faster and fully reliable (free of inevitable human/manual errors):

  1. Reqtify pilot project fully automates the traceability/consistency when the configuration of the tool has been properly done with the relevant links between SW work products (e.g. SW Requirement Vs SW Qualification, SW Design Vs SW Integration Testing, Source code Vs Unit Testing…) and the correct “regex” scripts well defined.

• Do not impact the existing process in terms of generated SW work products including their configuration/version management ensured with Tortoise SVN tool:

  1. The existing process is improved/automated but not changed: we still have the same SW work products in the same format (with additional tags/labels/attributes) and managed in version control with the same Tool (Tortoise SVN) and in the same repository.

• Provide the SW and Verification teams with accurate metrics about the implementation and coverage rates of the SW requirements at SW Component and overall MCAL levels, with the distinction of functional, non functional and safety critical requirements, and with the verification of the consistency between the versions of the requirements/design/code/test cases:

When I had to stop working on the pilot project, the implementation and coverage metrics were automatically provided to the user, with:

1. 3 different levels of information: At SW work product level (SW Requirement spec., Design documents, Test Plan/Reports…), At SW Component level (PWM, SPI, CAN, GPT…) and at overall MCAL level.

2. The implementation rate in Design and coverage rate in Testing for the 3 types of functional, non functional and safety critical requirements

3. The verification of the consistency between the versions of the requirements/design/code/test cases: if a SW requirement version is incremented, Reqtify makes it clear what the design elements and test cases that may need to be updated according to the changes of the SW requirement related to its new version: this is a powerful feature for the impact analysis when a significant number of SW requirements are modified (and their versions upgraded).

   This work has been documented in a presentation available on ResearchGate website, don't hesitate to review and comment it at this link.

Rewards:

12 months contract extended 12 more months and proposal for permanent hiring

10% Increase of the rate at the contract extension

Full autonomy on the Audits of approx. 20 AUTOSAR, Industrial and Renesas development kits (HW/SW) projects per month

Full autonomy on the Functional Safety Audit on the AUTOSAR MCAL ASIL B raised as one of the main strengths by a recognized External ASPICE/ISO26262 Assessor & 2 QA Managers from our German customer HELLA.

Approval of my proposal for the Transformation project of the traceability and consistency of the  SW lifecycle items

Again, a very good welcoming from my colleagues, including a German one from Düsseldorf, and a great experience in London city!