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

QUALITY ASSURANCE / PROCESS IMPROVEMENT

• First time 2 internal ASPICE Assessments (performed with a highly skilled co-assessor, the FuSa & SWQA Manager, certified ASPICE Provisional Assessor and Functional Safety Professional as well, and whose recommendation is added in the dedicated section ), lead to:

  • a tangible awareness from Senior Management and CTO of the critical situation of the Documentation / Configuration / Version Management practices (low level SW & high level documentation management findings) in terms of cost, time efficiency and maturity (potentially several millions euros/year to save once fixed on all LEM sites and an increased level of CM process maturity clearly required to comply with ASPICE, IATF 16949 and ISO 26262).

  • a Major internal company-wise initiative sponsored/approved by the CTO based on my Assessment results and the road map with its 6-7 Work Packages I defined and that resulted in the hiring of a Senior Consultant to implement this initiative in LEM Product Development Process.

  • To be noted, the VP Quality/Safety said during the conclusion meeting of the first interim assessment “with Antoine, we don’t need any external agency to perform our ASPICE assessments”.

• First time the findings raised during the internal ASPICE Assessment and the SW PPAP action plan are properly tracked in CodeBeamer ALM.

• 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 an independent Authority (V&V, QA, FuSa, CS, PQE, external IATF/ISO certification body…) detects that the automatic Polyspace (Bugfinder/Codeprover) source code analyses have been deactivated from the CI/CB/CD process for a while, potentially hiding major defects and causing bottleneck effects at the EOF the project.

• Huge rework of the QAP template structure and content (Quality Assurance Plan) to document a brand new QAP in Confluence web based tool and use its features to organize the first very effective and collaborative formal and informal reviews of the QAP in LEM Tech France on an ASIL B Residual Current Detection Sensor: 71 informal review findings raised by Project Quality Engineer, FuSa Manager, SW Lead, System Engineer and Project Manager in Confluence tool using its “resolved/unresolved comments” feature + 30 formal review findings raised by an independent SWQA Engineer using the first template of Formal Work Product Review Form including automatic KPIs that I created during the first week of my contract in LEM Tech France (Pivot tables).

• First time a formal Work Product/Project Plan (QAP) integrated an 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 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.

FUNCTIONAL SAFETY

• 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 a formal External ISO 26262 Functional Safety Assessment 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.

• 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.

• 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 “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.

BACKUP SW PRODUCT LEAD

• As part of my usual Technical Project/Product Management SUPPORT and unexpected pure backup SW Product Lead responsibilities (“firefighter”, due to the sudden unavailability of the usual assigned SW Lead & the identification of accumulated shortfalls in terms of SW Project Management, OEM/Tier-1 SW lifecycle joint reviews and other missing tasks)

  • After the 1-to-1 meeting with the Snr Product Manager EU/US and the requirements from the VP Quality in the latest Weekly FuSa/QA/CS Meeting who both got me understand the urgent situation and both technical & business-CRITICAL challenges to achieve the objectives of the SW PPAP and SOP milestones on this project (meaning delivering the Release Candidates on time and with the expected level of quality/scope agreed with the customer and checked during the formal Delivery review meeting online sessions and the formal PPAP joint review with this OEM), my approach has been:

    • first to negotiate with the OEM Purchase/Quality Engineer and Component Owner a reduced package of required work products to release in the scope of the formal PPAP milestone, which was only 10 work products out of more than 20 PPAP expected items, mainly based on the rationale that the excluded items were not relevant anymore at this advanced stage of the project and that we should only focus on the most helpful deliverables to monitor the SW project properly until PPAP, SOP milestones and maintenance phases. This negotiation ended successfully and allowed us to avoid low-added value workload and save a lot of time for the SW staff urgently needed to implement/fix/test blocking and major change requests / bugs before PPAP and SOP (including major issues with the Algorithm SW Component developed in MBD with Simulink).

    • Then, to avoid as much as possible the “documentation for documentation” vicious circle which is totally counterproductive on all aspects in the short and mid/long term for the company, its projects, and staff motivation/wellness, I decided to do the opposite of what has been done for the first 2 joint reviews of the SW lifecycle (the 3rd one has been only 30% done, the 4th one not done at all); consequently, for the 5th joint review corresponding to SW PPAP milestone, we were in a very uncomfortable situation to catch up all work not done on due time: to compare to the overall product level lifecycle, it’s like you must deliver the C-samples without having previously produced and validated A & B-samples… On top of that, the deliverables released for the 1st and 2nd joint reviews were using Volvo Templates but filled with totally irrelevant or irrealistic information: the SW Development Plan, SW Quality Assurance Plan, SW Progress Report (and other work products using Volvo templates) were naïvely reflecting what the OEM wanted to see, instead of mapping to Volvo QDPR (Standard Development Process), which may be implemented in numerous different ways, what has really been done by LEM so far and what will be done until SOP and series life. As I said, I wanted to avoid filling 10 documents internally with the terrible "documentation for documentation” mindset which is totally useless and kills the motivation of the staff members, who then are disgusted by what they THINK process improvement is, which is not at all the correct outcome when ASPICE and Volvo QDPR process are properly planned and implemented in a smart way, like we’ve got CMMI being successfully deployed at VALEO in 2007 for the first time in the French Industry.

• first time the Volvo template of SW Submission Warrant and SW Delivery review form have been properly documented and signed by myself when delivering the release candidates for PPAP and SOP, providing LEM Tech France with 2 formal & tangible high level & detailed product release baselines, the Warrant linking all important SW, HW, legal, admin, project, product, responsibilities and relevant information together, and the Delivery Review form providing a quite complete report of the SW activities / progress in terms of work products maturity, requirement implementation & coverage rates, defect status, planned changes, the different levels of testing results, CPU/RAM/ROM consumption, Planning/Risks/Quality status like 2 different levels of snapshot captured for each key project milestone => it required a lot of coordination (and hands-on production of required PPAP items) of all SW domains/interfaces, from the defect synthesis with the TPL and complex interface with system engineering to the architectural design produced by the Group Head of SW, the Head of SW and the SW team in Bulgaria and the V&V Manager for all testing results => strong evidence of release baselines management to present in case of customer or external audits/assessments and internal Configuration Audits + formal written congratulations received from the Component Owner of the OEM/Volvo Trucks for the PPAP SW Release Candidate delivery review milestone in July 2023.

• Significantly changed the internal structure and content of Volvo SW Development Plan template (description of the real internal practices/tools/templates + Major SW project-specific information) and the SW Progress Report (export of Codebeamer ALM KPIs really used to plan/track the progress of the SW team in Bulgaria, all this done in collaboration with the Head of SW based in Sofia, instead of manual KPIs not used at all, and to be documented in a Word template).

• First time the very exhaustive Volvo template of SW PPAP checklist is used in LEM: a lot of checkpoints covering all processes from RFQ/tendering to industrialization, mass production, delivery, and maintenance. Collected all required information to document this key checklist to be presented during the SW PPAP milestone review, conditioning our success in this major milestone, on top of the SW Delivery review done 2 weeks ago (see 2 points above).

• First time a concrete and formal Risk Management process has been established including a Risk Management Plan documented in Confluence and covering all requirements from applicable standards (ASPICE Risk Mgt process, CMMI PP/PMC process area, ISO 26262 Part 2 and the latest version of the IATF 16949 which now insists on the need to manage all risks properly) and a formal Risk Tracker in Codebeamer ALM that implements Risk Mgmt Plan requirements.

VALEO CMMI L2 PROJECT

In charge of SW Quality Assurance activities throughout SW Development Lifecycle, mainly performed through monthly project audits supported by an Audit Workbook defined by the SWQA workgroup from CMMI project:

Auditing of 3 series projects (Volvo X60, Renault Laguna, Citroën C6) covering all CMMI processes from Project Planning, Monitoring and Control, Process and Product QA, Supplier Agreement Management (Acquisition of CAN MCAL driver + LIN conformance tests performed externally before I integrated the LIN Emulator in our Automatic Test Bench allowing internal and automatic LIN characterization and testing, see below chapter), to Configuration & Change Management, Requirement Management, and Measurement (KPIs collection and analysis). The Audit Workbook was documented on a monthly basis during a 2 hours interview with the SW Project Lead, then the Audit results were reported to the SW Director (also acting as CMMI Project Manager) and the Engineering Quality Director both based in Paris area, and the Electronics Department Manager, the Project Quality Engineer and the entire SW Team all based in Angers. Results consisted in different charts, graphs and KPIs showing the level of compliance of each process with CMMI and our internal Standard SW process defined by the SEPG (SW Engineering Process Group) and its Process Owners and workgroups. These Audit results were printed and displayed on a monthly basis on the System and SW Board located in the R&D open space

Member of the CMMI L2 project: CMMI Introduction training, evaluation and reporting of the process deployment.

For both sites, Paris (P2: Prototypes, mock-up, standard SW components...) and Angers (P1: mass production customer projects reusing some standard components from Paris, external CAN driver and adding the entire Application Layer developed in MBD and automatic Code generation), gathering of all SW work products compliant with CMMI L2 on 3 mass production projects from Angers and 2 standards SW components development projects from Paris to fill in the CMMI Appraisal Database managed in "Appraisal Assistant" tool (free open source SW tool developed by an US based University), CMMI Appraisal Team Member (CMMI ATM) part of the 2 ATMs "mini-team" responsible for auditing PM and SAM processes against CMMI L2. Also successfully audited on PPQA process which I was responsible for on Angers site.

First Automotive Tier-1 achieving CMMI Level 2 compliance in France in 2007, key success for both VALEO reputation in engineering quality/efficiency and to achieve business objectives (ability to be awarded in key RFQs with OEMs requiring CMMI and then ASPICE and ISO 26262 compliance).

VALEO SW Factory Automation: from Model in the Loop to LIN/CAN/PWM V&V automated testing

o In charge of the SW Validation Testing activities for all Customer projects (Renault, Volvo, PSA)

o Managed a SW Test team (1 offshore Test engineer who I trained to the entire SW Validation process and tools during 2 weeks onsite, 1 Engineering intern during 3 years with only 20% of time at school, 1 or 2 onsite contractors on adhoc basis).

o Only SW Staff member who a specific budget (not included in customer projects finances) was allocated to (used to improve SW Validation processes, templates, tools, and to develop & release new features for our Automatic SW Test Bench).

o Estimation, Planning (and hands-on Execution when high workload) of the SW Test activities: SW Validation Workload Plan, SW Validation Strategy (including detailed description of the Automatic Validation Test Bench and process), SW Validation Test Plan, SW Validation Test Report, SW Validation Test cases traceability to Component Requirement Specification (ECU) using Reqtify Tool, Testing coverage: reached 100% coverage of the CRS thanks to fully automated testing campaigns when both CAN traminator and LIN emulator have been integrated into the Test Bench by myself: no need to manually create the CAN and LIN fault injection tests anymore (Bus off, Open circuit, short circuit to Vcc or Ground, Data crush/corruption...), all CAN & LIN characteristics and potential failures were tested through the automation of the CAN traminator and LIN Emulator, which led us to exceed the scope of validation to cover a broad spectrum of software and hardware verification for LIN and CAN (see pictures below).

o Responsible for developing and maintaining our internal automatic SW Test bench: in particular, I added a LIN Emulator (emulating LIN Masters/Slaves) fully automated thanks to its monitoring via CAN communication programmed in C coding (Labwindows CVI IDE). Able to inject Bit crush faults on any data of the LIN frames exchanged between our ECU (LIN Master) and our LIN slaves/actuators (real or simulated step motors that control the dynamic front lamps). Similarly, I integrated the CAN Traminator ESL to perform all CAN fault injection tests and protocol characterization. I also implemented the generation, acquisition and processing of PWM signals (from the HMI to the low level C code) using a standard NI DAQ board (DIO/AIO): this has been reused by the System Test Team to integrate PWM measurements into the System Qualification Test Bench monitored by TestStand (NI Test sequencer) which easily reused the PWM acquisition and processing module developed by myself with NI technologies as well (Labwindows CVI + NI DAQ board). In addition to my initial Model Based Design activities with automatic C code generation, I have also integrated the possibility of defining test cases in the Rhapsody/Statemate modeling tool and reusing them in our automatic test sequencer to loop back the tests performed in MIL (Model in the Loop) with the tests conducted in HIL (Hardware In the Loop).

I have been rewarded in different ways throughout my experience at VALEO for nearly 3 years: first, by seeing my first 8-week contract extended after the delivery of my first embedded software in mass production, then by being hired by VALEO after 8 months among 5 contractors to replace the Validation and Quality Manager who was leaving the company to return to his home region (see his recommendation below, he was my technical manager during my first months at VALEO). I was then the engineer who received the best salary increase in the electronics department for the next 2 years, I secured 2 cross-departmental budgets dedicated solely to me outside of client budgets, I obtained a full-time VALEO Offshore resource (Egypt) in addition to the apprentice engineer who worked under my technical supervision 80% of the time, and I occasionally had 1 or 2 contractors on site who worked on my activities when there was an overload, and I received 3 additional days off following the CMMI L2 evaluation.

But the best reward I had in this experience at Valeo is having met several brilliant personalities, including one engineer in particular, a young graduate who ranked 2nd in his class at the 2nd engineering school in France, Centrale SupElec, just behind the inevitable Ecole Polytechnique. This young man and I performed 'Two men shows' in the company restaurant and at Team Building events, which remain memorable moments for me.

After my departure, I thanked my colleagues and friends Sébastien (from Centrale SupElec), Erwan, Gino, Samuel, Emmanuel, Baptiste, and a few others in a message for the fantastic human experience I had with them over the past 3 years.

"Well integrated into the software and system teams, Antoine was able to meet the reliability, security, and quality requirements of the automotive industry. On various embedded and real-time software projects, he ensured software and functional validations, while integrating methods (CMMI, software quality assurance,...) and the high level of quality expected by Valeo. Mastering the advanced technical aspects of embedded electronics and vehicle networks, he was able to evolve tools, oversee projects, and manage validations."

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). 🙂

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.

LEM TECH France Quality Assurance & Functional Safety + backup SW Product Lead

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.

LEM offered me a permanent contract, but we were not ready at that time (end of 2023) to leave our house in Murcia for several reasons:

- we had organized a move from Barcelona to Murcia in 2021 for nothing, as I never needed to go to the office in Murcia;

- we had only been in Murcia for 2 years, while we still wish to stay at least 3-4 years where we move, otherwise it is impossible to have a stable professional and personal life;

- we had just 'fought' legally against our dishonest landlord who tried to evict us illegally to install his friends in our place. We suffered harassment from the maintenance supervisor of the house and his wife, who are friends of the landlord. We had to hire a lawyer and pay her several hundred euros to prove that it was impossible to evict us from the house before December 31, 2025, even with a notice, given that the owner had established 11-month leases and had agreed to renew the first lease.

- we had already raised our son for 2 years in a Catalan context (all schools/nurseries are in Catalan in Barcelona and everyone speaks in Catalan, not in Spanish), he started to say words in Catalan, understand Catalan, sing in Catalan, and we suddenly integrated him into a 100% Spanish environment at the age of 2: it took him over a year to catch up with the other children and he was very shy in his interactions with adults for a long time because of that. We did not want, barely 2 years later, to impose a new brutal change of environment on him while he was in the process of catching up and was perfectly integrating with his classmates and extracurricular activities (soccer, taekwondo, swimming). Now, he is almost 7 years old, he speaks French and Spanish fluently (and is starting to speak English), he would be sad to leave his best friends but he is very sociable and I am sure he would perfectly integrate in Germany. If we would relocate to Frankfurt, he would very probably goes to the "Lycée Français Victor Hugo" where he could keep on learning German, English, French and Spanish. Regarding Soccer, Taekwondo and swimming, I'm sure we would find what he needs.

MOTOROLA - Innovative & Cost-Performant Multi-Coding Bit Error Rate Measurement System

As RF Test Characterization Engineer/Intern in Motorola Semiconductors, I designed and developed an innovative, reliable and very cost-performant automated Bit Error Rate measurement system for low data rate receivers based on standard digital I/O interfaces (National Instruments DIO card) and post processing clock recovery software. The system has then been validated internally and used for the formal characterization of RF ICs going to mass production. The system has also been presented during the IEEE-IMTC Conference 2005 in Ottawa.

Radio Frequency (RF) integrated receiver circuits are now extremely common in a wide range of applications where wireless data transmission occurs within short distances (less than 100m) using low data rates (in the range of some kbits/s):

- Automotive: remote keyless entry, passive entry, tire pressure and temperature monitoring.

- Home automation: remote metering, remote control of alarms and small appliances.

- Computing: mouse, keyboard.

- Medical monitoring: insulin pumps.

Most of these applications are using miniature cost effective RF modules based on integrated circuit (IC) technology and target a long battery lifetime (6 months to 6 years depending on the application) difficult to reach when complex integrated circuits based on communication standards are used.

For example Bluetooth is oversized in terms of speed and system features (such as channeling, modulation scheme or embedded protocol) for the targeted performances, and demonstrates too high of a current consumption. Simple proprietary communication links are used instead, with elementary OOK (On Off Keying) or FSK (Frequency Shift Keying) modulation schemes, coding formats such as Manchester or Miller and packet profiles including delimiters, checksum and/or redundancy. Performances of these proprietary links can be measured using the device packet format but a faster measurement of error rate is possible if the capability to receive a continuous stream of data is added as test functionality to the RF IC design.

This tool is built around a commercial digital I/O (DIO) board and proprietary application software developed using LabVIEW™ allowing simultaneous BER measurements over up to 7 reception channels. The performances, targeted to cover the characterization of the applications listed, are in the range of BER = 10-5.