← Pagina iniziale

Sviluppo embedded critico secondo le norme

Oltre 35 anni di esperienza in sicurezza funzionale, sistemi di tempo reale e sviluppo prossimo all'hardware — familiarità con le norme rilevanti per automotive, medicale e industria.

Lo sviluppo embedded critico non è una questione di funzioni isolate ma di approccio complessivo: dall'analisi dei requisiti all'architettura e all'implementazione, fino alla verifica e alla documentazione. Chi commissiona in questo ambito non cerca solo un buon programmatore, bensì qualcuno che abbia compreso l'interazione tra norma, metodo e codice — e che sappia stimare in modo realistico lo sforzo che la conformità implica.

I tre ambiti di competenza seguenti sono la base del mio lavoro. Si sovrappongono in quasi ogni progetto.

Esperienza

1. Esperienza

Oltre tre decenni di sviluppo embedded — dall'inizio carriera nello sviluppo motori all'attività attuale di consulente indipendente. Nel segmento premium l'esperienza non è un argomento di marketing ma un prerequisito: chi sviluppa sistemi di tempo reale prossimi all'hardware o firmware critico ha bisogno della memoria delle modalità di guasto che non compaiono nei manuali.

Oltre 35 anni di sviluppo embedded (dal 1990)
Inizio carriera in Mercedes-Benz, Stuttgart-Untertürkheim
Progetti per diversi grandi costruttori in Germania, Regno Unito e Stati Uniti — e per i loro fornitori francesi e tedeschi
Attività internazionale in Germania e Francia
2002 — fondazione di Navimess Elektronik (in seguito chiusa)
2012 — fondazione di SCHMITT CONSULTING S.A.R.L. in Francia
Diplom-Informatiker (FH), specializzazione Informatica Tecnica
Tesi di laurea in regolazione automatica con driver hardware in tempo reale in assembler

Norme

2. Norme e standard

Familiarità con le norme rilevanti per lo sviluppo critico in automotive, medicale e industria. «Familiarità» significa qui: conosco i requisiti, i metodi e le insidie tipiche — e posso valutare quale sforzo normativo si adatta al vostro progetto e quale sarebbe sproporzionato. Nei progetti opero come sviluppatore all'interno del quadro di conformità stabilito dal cliente; non assumo un ruolo autonomo di auditor normativo.

ISO 26262 — Sicurezza funzionale (automotive, ASIL A a D)
IEC 61508 — Sicurezza funzionale (industria, SIL 1 a 4)
IEC 62304 — Ciclo di vita del software (dispositivi medici, classi A/B/C)
IEC 60601-1 — Sicurezza dell'apparecchio (medicale)
RTCA/DO-178B — Software aeronautico (DAL A a E)
Automotive SPICE — Valutazione dei processi nei progetti automotive
MISRA-C / MISRA-C++ — Regole di codifica per software C/C++ critico

Gestione

3. Gestione di progetto

I progetti embedded raramente falliscono sul piano tecnico, spesso falliscono sulla comunicazione e sulla guida. La mia gestione di progetto è allineata a ciò che si aspettano i clienti del segmento premium: tempi tracciabili, costi trasparenti, passaggi di consegna chiari. Non lavoro con metodologia sovraccarica, ma con ciò di cui un progetto ha realmente bisogno.

Controllo rigoroso di tempi e costi
Coordinamento regolare con il cliente alla cadenza concordata
Preventivi con garanzia di prezzo per contratti a forfait
Trasferimento di conoscenze ai team del cliente al termine del progetto
Coordinamento di fornitori esterni e funzioni interne
Documentazione tecnica e consegna del codice tracciabile
Disponibilità a firmare NDA e trattamento riservato dei contenuti del progetto

Aree tecniche aggiuntive

Oltre ai tre campi principali, 35 anni di pratica hanno fatto emergere diverse aree di fondo che spesso fanno la differenza nei progetti:

Sistemi di tempo reale e sviluppo bare-metal: Programmazione prossima all'hardware su microcontrollori limitati, con o senza sistema operativo di tempo reale. Esperienza con temporizzazione deterministica, architetture a interrupt e ottimizzazione sotto vincoli di memoria e tempo di esecuzione.
Verifica FPGA: Sviluppo in VHDL e SystemVerilog, con testbench e verifica sistematica. I progetti FPGA non sono «software su un chip» — seguono regole proprie, ed è proprio qui che molti progetti falliscono.
Ripresa di codice e reverse engineering: Analisi di basi software ereditate — assembler, C, C++, spesso senza documentazione — e loro preparazione sistematica per il team del cliente. Il progetto Stihl (vedi referenze) ne è un esempio.
Cifratura e comunicazione sicura: Sviluppo di procedure crittografiche e di comunicazione bus sicura in contesto embedded, dove le librerie standard non si adattano — dagli aggiornamenti di firmware firmati ai bootloader sicuri, passando per soluzioni di cifratura su misura. Nota: oltre un certo livello di cifratura può essere necessaria un'autorizzazione dell'autorità competente, poiché alcune tecnologie di cifratura non possono essere esportate in tutti i paesi. La necessità di autorizzazione viene esaminata insieme prima dell'avvio.

Cosa significano queste competenze per voi

Se avete un progetto in cui la conformità alle norme, i requisiti di tempo reale o la complessità prossima all'hardware giocano un ruolo — e allo stesso tempo non volete ingaggiare un intero team di specialisti ma una persona con visione d'insieme e impegno di consegna — allora una cooperazione è probabilmente adatta.