Het inzetten van neurale netwerken in veiligheidskritische automotive-, industriële en embedded systemen vereist het verzoenen van twee fundamenteel verschillende technische filosofieën: de probabilistische, datagedreven wereld van machine learning en de deterministische, op bewijs gebaseerde wereld van functionele veiligheid. Deze gids verklaart de normen die deze omgevingen reguleren — ISO 26262, SOTIF/ISO 21448, IEC 61508 en IEC 62443 — en hoe je een ML-implementatie structureert die een veiligheidsingenieur kan accepteren.
Laatst herzien: mei 2026
Functionele veiligheid is het deel van de algehele veiligheid van een systeem dat afhangt van de correcte werking van elektrische, elektronische en programmeerbaar elektronische componenten. Wanneer een AI- of ML-component wordt ingezet in een veiligheidskritisch systeem — autonoom noodremmen, industriële noodstop, robotische bewegingsplanning — vereisen de normen voor functionele veiligheid bewijs dat het systeem veilig faalt, zich correct gedraagt binnen zijn gedefinieerde bedrijfsomstandigheden en hardware- en softwarefouten kan tolereren. De uitdaging voor machine learning is dat deze normen zijn ontworpen voor deterministische software, en neurale netwerken in de traditionele zin niet deterministisch zijn.
De normen voor functionele veiligheid die automotive- en industriële systemen reguleren — ISO 26262, IEC 61508, IEC 62061 — zijn ontwikkeld voor deterministische software: code die invoer verwerkt via gedefinieerde logica en uitvoer produceert die formeel kan worden gespecificeerd, getest tegen structurele dekkingscriteria en geverifieerd als correct binnen de bedrijfsomstandigheden van het systeem.
Neurale netwerken passen niet in dit model. Ze worden getraind — niet geprogrammeerd — en hun gedrag komt voort uit miljoenen geleerde parameters in plaats van expliciete logica. Dezelfde invoer die tweemaal wordt aangeboden, kan licht verschillende uitvoer opleveren afhankelijk van het floating-pointgedrag van de hardware en de threadplanning. Hun faalwijzen zijn statistisch, niet deterministisch: ze presteren gemiddeld goed maar kunnen falen op specifieke invoer die ondervertegenwoordigd was in de trainingsdata. En ze kunnen niet uitputtend worden geverifieerd tegen een formele specificatie, omdat er geen formele specificatie bestaat — de specificatie is impliciet in de trainingsdata.
Dit creëert een fundamentele spanning die elke ingenieur die AI in een veiligheidskritisch systeem inzet moet oplossen: hoe bouw je een veiligheidsdossier voor een component waarvan het gedrag in de traditionele zin niet formeel kan worden gespecificeerd of geverifieerd? Het antwoord — dat nu opkomt uit normalisatie-instellingen, brancheconsortia en vroege programma-ervaring — combineert architectuurpatronen (veiligheidsmonitors, ODD-definitie, terugvalpaden) en statistisch bewijs (grote validatiedatasets, robuustheidstests) die samen een verdedigbaar veiligheidsdossier vormen.
De zes kernspanningen hieronder vertegenwoordigen de technische uitdagingen die elke veiligheidskritische ML-implementatie moet aanpakken.
Normen voor functionele veiligheid (ISO 26262, IEC 61508) gaan uit van deterministisch gedrag: bij dezelfde invoer produceert een veiligheidsfunctie telkens dezelfde uitvoer. Neurale netwerken die zijn getraind met stochastische gradiëntdaling en dropout bieden deze garantie niet. Zelfs identieke invoer kan licht verschillende uitvoer opleveren afhankelijk van de floating-pointimplementatie van de hardware en de threadplanning.
Veiligheidsdossiers vereisen traceerbaarheid — je moet kunnen uitleggen waarom een systeem een beslissing neemt en aantonen dat er binnen het gedefinieerde operational design domain (ODD) geen onveilige beslissing mogelijk is. Diepe neurale netwerken zijn fundamenteel ondoorzichtig. Verklaarbaarheidsmethoden (SHAP, LIME, attention-maps) leveren benaderingen, geen bewijzen.
Een model dat is getraind op een distributie van trainingsdata kan zich onverwacht gedragen op invoer die buiten die distributie valt — een probleem dat bekendstaat als distributieverschuiving. Veiligheidsnormen vereisen dat het systeem zich correct gedraagt over zijn volledige gedefinieerde set bedrijfsomstandigheden. Distributieverschuiving is fundamenteel in strijd met deze eis.
Traditionele veiligheidskritische software wordt geverifieerd tegen formele specificaties met behulp van structurele dekkingsmetrieken (MC/DC voor ASIL D). Neurale netwerken kunnen niet op deze manier worden geverifieerd — de 'specificatie' is impliciet in de trainingsdata. Statistische validatie op grote, achtergehouden datasets vervangt formele verificatie, maar veiligheidsautoriteiten verschillen van mening over wat voldoende bewijs vormt.
Voor veiligheid gecertificeerde software is onderworpen aan streng wijzigingsbeheer: elke aanpassing vereist herbeoordeling. Neurale-netwerkmodellen kunnen worden bijgesteld, bijgewerkt of vervangen naarmate data zich opstapelen. Elke update kan het bestaande veiligheidsdossier ongeldig maken en hervalidatie vereisen — wat een spanning creëert tussen operationele verbetering en het onderhoud van de certificering.
Edge-veiligheidssystemen hebben krappe end-to-end-latentiebudgetten — vaak onder de 10ms voor realtime regelkringen. Inferentie van neurale netwerken op beperkte hardware (MCU's, FPGA's, kleine SoC's) moet binnen dit budget passen en tegelijk marge laten voor de rest van het regelpad. Kwantisatie en pruning helpen, maar introduceren hun eigen faalwijzen.
ISO 26262 is de norm voor functionele veiligheid in automotive, van toepassing op wegvoertuigen met een maximaal toegestane massa (MGVM) tot 3.500 kg. Ze definieert het Automotive Safety Integrity Level (ASIL)-raamwerk — vier niveaus (A tot en met D) die de striktheid bepalen van het vereiste veiligheidsengineeringproces voor een gegeven veiligheidsfunctie. ASIL D is het strengst; ASIL A het minst.
Het ASIL-niveau voor een functie wordt bepaald via een gevarenanalyse en risicobeoordeling (HARA) die drie factoren beschouwt: de ernst (S) van de mogelijke schade, de blootstelling (E) aan de gevaarlijke situatie en de beheersbaarheid (C) door de bestuurder of operator. De combinatie van S, E en C bepaalt de ASIL-toewijzing.
Het V-model is het raamwerk van het ontwikkelproces: eisen worden gespecificeerd en ontleed op de linkerarm van de V; de implementatie bevindt zich onderaan; integratie, verificatie en validatietests bevinden zich op de rechterarm, als spiegel van elk artefact op de linkerarm. Elke veiligheidseis moet worden getraceerd vanaf het veiligheidsdoel op voertuigniveau via systeem-, hardware- en softwareniveaus, en geverifieerd op het overeenkomstige niveau op de rechterarm.
SOTIF (ISO 21448:2022) breidt ISO 26262 uit naar gevaren die voortkomen uit de beperkingen van de beoogde functie zelf — niet uit storingen, maar uit situaties waarin het systeem zich precies gedraagt zoals ontworpen, terwijl het ontwerp ontoereikend is voor de werkelijke bedrijfsomstandigheden. Dit is direct relevant voor ML: een perceptiemodel dat een voetganger verkeerd classificeert bij ongewone belichting 'faalt' niet in de traditionele zin — het werkt zoals het is getraind, maar de training was ontoereikend voor die omstandigheid. SOTIF-analyse vereist het identificeren en systematisch testen van deze triggerende omstandigheden.
Laagste eis voor functionele veiligheid. Van toepassing op systemen waar de ernst van het gevaar laag of de blootstelling weinig frequent is.
Implicatie voor ML-implementatie
Statistische validatie op matige testsets kan worden geaccepteerd. Basale runtime-monitors volstaan.
Matige veiligheidseis. Vaak toegepast op rijhulpfuncties met matig gevaarpotentieel.
Implicatie voor ML-implementatie
Vereist een gedocumenteerde ODD, prestatiemetrieken voor de grensgevallen van de ODD en bewaking op invoer buiten de distributie.
Hoge veiligheidseis. Van toepassing op systemen waar storingen zonder externe mitigatie tot ernstig letsel kunnen leiden.
Implicatie voor ML-implementatie
Volledig veiligheidsdossier vereist. Runtime-assurance-monitors, een expliciet terugvalpad en SOTIF-analyse verplicht. Een beoordeling door een derde partij wordt doorgaans verwacht.
Hoogste niveau van functionele veiligheid in automotive. Van toepassing op systemen waar een storing tot levensbedreigende gevaren kan leiden.
Implicatie voor ML-implementatie
Neurale-netwerkcomponenten worden doorgaans beperkt tot perceptie-/adviesrollen, nooit in het uiteindelijke veiligheidskritische regelpad. Redundante deterministische monitors zijn vereist. Huidige industrieconsensus: zuivere ML-componenten zijn als enige veiligheidsfunctie niet certificeerbaar tot ASIL D.
IEC 61508 is de generieke norm voor functionele veiligheid van elektrische, elektronische en programmeerbaar elektronische (E/E/PE) veiligheidsgerelateerde systemen. Het is de moedernorm waaruit sectorspecifieke normen zijn afgeleid: IEC 62061 (machines), EN 50128 (spoor), IEC 61511 (procesindustrie) en IEC 61513 (nucleair). Het Safety Integrity Level (SIL)-raamwerk is het equivalent van ASIL voor IEC 61508 — vier niveaus (SIL 1–4) gedefinieerd door de vereiste faalkans op aanvraag (PFD) voor een veiligheidsfunctie.
Voor AI-implementaties in industriële systemen is de kernvraag: welk SIL-niveau wordt toegewezen aan de veiligheidsfunctie waaraan de AI-component bijdraagt? Dit bepaalt de striktheid van het vereiste validatiebewijs en de beperkingen op hoe de AI-component binnen die functie kan worden gebruikt.
Het algemene principe is hetzelfde als in ISO 26262: neurale-netwerkcomponenten kunnen bijdragen aan functies met een lager SIL als adviserende of initiërende elementen, maar de veiligheidsfuncties met de hoogste integriteit vereisen deterministische implementaties of deterministische veiligheidsmonitors die de uitvoer van de ML-component overrulen.
Laagste veiligheidsintegriteitsniveau. Van toepassing op functies waarbij een enkele storing zonder meerdere bijdragende factoren onwaarschijnlijk een gevaarlijke gebeurtenis veroorzaakt.
ML-opmerking
Op ML gebaseerde adviessystemen die een SIL 1-veiligheidsfunctie voeden, moeten statistische betrouwbaarheid binnen de gedefinieerde bedrijfsomstandigheden aantonen.
Tussenniveau. Gangbaar in veiligheidsgeïnstrumenteerde functies in de procesindustrie: noodstops, activering van drukontlasting, brand- en gasdetectie.
ML-opmerking
ML-anomaliedetectie die een SIL 2-noodstop voedt, moet worden behandeld als een initiërend element in de veiligheidslus — de kans op onbedoelde werking (gevaarlijke storing) ervan moet worden aangetoond.
Hoog integriteitsniveau. Te vinden in noodsystemen van chemische fabrieken, spoorwegseinen en ondersteunende functies voor nucleaire instrumentatie.
ML-opmerking
Neurale-netwerkcomponenten worden momenteel door de meeste certificeringsinstanties niet geaccepteerd als SIL 3-implementaties van veiligheidsfuncties. ML kan diagnostiek of niet-veiligheidskritische datapaden ondersteunen naast een bewezen deterministische veiligheidslaag.
Hoogste niveau van IEC 61508. Beschermingssystemen voor kernreactoren, vitale spoorwegfuncties. In de praktijk uiterst zeldzaam.
ML-opmerking
Op dit moment wordt geen enkele ML-component op SIL 4 geaccepteerd als onderdeel van de veiligheidsfunctie zelf.
IEC 62443 is de internationale reeks normen voor de cyberbeveiliging van industriële automatiserings- en controlesystemen (IACS). Ze definieert een zone-en-conduit-model: het OT-netwerk wordt verdeeld in zones op basis van de kriticiteit van de erin opgenomen assets, en communicatie tussen zones moet door gedefinieerde conduits met passende beveiligingsmaatregelen verlopen.
Voor AI-implementaties is de IEC 62443-vraag: in welke zone bevindt de AI-inferentieserver zich, en welke beveiligingsmaatregelen reguleren zijn communicatie met het controlenetwerk? Het plaatsen van een AI-inferentieserver die rechtstreeks met PLC's of veldapparaten communiceert zonder passende conduit-maatregelen schendt het zonemodel en creëert een cyberbeveiligingsrisico — een aanvaller die de AI-server compromitteert, verkrijgt een toegangsweg naar de controlezone.
Daarnaast vormen AI-systemen een nieuw aanvalsoppervlak: adversariële invoer — zorgvuldig vervaardigde invoer ontworpen om het model onjuiste uitvoer te laten produceren — kan veiligheidsrelevante storingen veroorzaken. IEC 62443-cyberbeveiligingsanalyse voor AI-systemen zou naast conventionele IT-beveiligingsmaatregelen ook tests van adversariële robuustheid moeten omvatten.
Zakelijke IT-netwerken — ERP, bedrijfse-mail, cloudconnectiviteit. Hier ingezette AI-modellen hebben het breedste aanvalsoppervlak en de minste OT-impact bij compromittering, maar ook de zwakste dataversheid en de hoogste latentie.
Richtlijn voor AI-plaatsing
Geschikt voor rapportage-AI, documentsamenvatting, bedrijfsanalytiek. NIET geschikt voor realtime besturing of veiligheidsnabije inferentie.
Supervisorische controlesystemen, historian-databases, SCADA-servers. Hier ingezette AI-inferentie kan via OPC-UA of OSIsoft PI realtime procesdata benaderen zonder directe toegang tot veldapparaten.
Richtlijn voor AI-plaatsing
Geschikt voor voorspellend onderhoud, advies over procesoptimalisatie, anomaliedetectie. Vereist IEC 62443-3-3-conduit-maatregelen naar Zone 2.
PLC's, DCS, veldcontrollers. Veiligheidskritische regelkringen draaien hier. AI-inferentie in Zone 2 is ongebruikelijk en vereist verharding op SL (Security Level) 2: authenticatie, versleutelde communicatie, auditlogging.
Richtlijn voor AI-plaatsing
Runtime-assurance-monitors en detectoren voor invoer buiten de distributie kunnen hier werken als de hardwarebeperkingen het toelaten. Directe verantwoordelijkheid voor een veiligheidsfunctie vereist een analyse van functionele veiligheid (ISO 26262 / IEC 61508).
Sensoren, actuatoren, slimme instrumenten. Uiterst beperkte apparaten — doorgaans MCU's of eenvoudige RTU's. AI-inferentie is hier beperkt tot TinyML-modellen (INT8-gekwantiseerd, kleiner dan 1MB) op speciale inferentie-coprocessoren.
Richtlijn voor AI-plaatsing
Anomaliedetectie op ruwe sensorstromen. Haalbaar met hardware van MCU-klasse op SL 1. Verantwoordelijkheid voor een veiligheidsfunctie op deze laag vereist een formele IEC 61508-beoordeling.
Hyperion adviseert over de AI- en edge-architectuurlaag: waar ML past binnen de veiligheidsarchitectuur, hoe je de veiligheidsmonitor en het terugvalpad structureert, welke edge-toolchain geschikt is voor je hardware, en hoe je het veiligheidsbewijspakket voorbereidt. Wij zijn geen certificeringsinstantie — maar we helpen je een architectuur te bouwen die een certificeringsinstantie kan accepteren.
Een veiligheidsdossier is een gestructureerd argument, ondersteund door bewijs, dat een systeem aanvaardbaar veilig is voor een gegeven toepassing in een gegeven omgeving. Voor ML-componenten moet het veiligheidsdossier de specifieke faalwijzen van neurale netwerken — distributieverschuiving, ondoorzichtigheid, non-determinisme — aanpakken met architectuurpatronen en statistisch bewijs in plaats van formele verificatie. De volgende zes elementen vormen de kern van een verdedigbaar veiligheidsdossier voor een ML-component aan de edge.
Definieer de precieze omstandigheden waaronder de ML-component geldig is: omgevingsomstandigheden, bereiken van invoerdata, werkbereiken van sensoren, snelheids-/belastingsenveloppen. De ODD is het contract tussen het ML-systeem en het veiligheidsdossier. Elke invoer buiten de ODD moet een veilige toestand activeren — het ML-systeem mag bij invoer buiten het domein niet stilzwijgend onveilige uitvoer produceren.
Een parallelle deterministische monitor — geïmplementeerd in conventionele software of hardware — bewaakt de uitvoer van de ML-component en blokkeert of overrulet elke uitvoer die de veiligheidsbeperking schendt. Dit is het standaardpatroon voor het inzetten van ML in veiligheidskritische systemen: de ML-component is adviserend, de deterministische monitor is gezaghebbend. De monitor zelf moet gecertificeerd zijn op het vereiste ASIL/SIL-niveau.
Een OOD-detector — doorgaans gebaseerd op de reconstructiefout van de invoer, ensemble-onenigheid of Mahalanobis-afstand — markeert invoer die buiten de trainingsdistributie valt. Bij OOD-detectie schakelt het systeem over naar het terugvalpad in plaats van door te gaan met inferentie. OOD-detectoren moeten in het veiligheidsdossier worden gevalideerd op hun eigen fout-negatiefpercentage.
Elke veiligheidskritische ML-implementatie moet een gedefinieerde terugval hebben: een veilige toestand waarin het systeem terechtkomt wanneer de ML-component faalt, wordt overruled door de veiligheidsmonitor of een OOD-invoer detecteert. De overgang naar de veilige toestand moet zelf ASIL/SIL-beoordeeld zijn. Gangbare terugvalpatronen: begrensde/conservatieve modus (lage snelheid, vergrote veiligheidsmarges), verzoek tot overname door bestuurder/operator, gecontroleerde stop.
Omdat formele verificatie (MC/DC-dekking) niet op neurale netwerken kan worden toegepast, neemt statistische validatie op een grote, onafhankelijke, representatieve testset haar plaats in. De omvang en samenstelling van de testset, de prestatiemetrieken en de betrouwbaarheidsintervallen moeten worden gedocumenteerd en geaccepteerd door de veiligheidsautoriteit. ISO PAS 21448 (SOTIF) en de aankomende ISO 8800 bieden opkomende richtlijnen.
De algehele veiligheidsfunctie wordt ontleed in subelementen, elk met een toegewezen ASIL/SIL-niveau. Aan de ML-component wordt doorgaans een lager ASIL/SIL-niveau toegewezen, waarbij het verschil wordt gedekt door de deterministische veiligheidsmonitor. Deze ASIL-decompositie moet formeel worden gedocumenteerd en beoordeeld. Het totale systeem moet voldoen aan de ASIL/SIL-eis op het hoogste niveau.
Opmerking over normen: De methodologie voor het opstellen van veiligheidsdossiers voor ML-componenten is volop in ontwikkeling. ISO/TR 4804, UL 4600 en de in ontwikkeling zijnde ISO 8800 (AI en wegvoertuigen) bieden de meest actuele richtlijnen. Certificeringsinstanties en automotive-OEM's stellen hun acceptatieposities over specifieke technieken nog vast — wat voldoende statistisch bewijs vormt, welke OOD-detectiebenaderingen aanvaardbaar zijn en hoe ASIL-decompositie van toepassing is op paren van ML- en conventionele software. Ga altijd vroeg in gesprek met je beoogde certificeringsinstantie om af te stemmen over het bewijspakket.
Veiligheidskritische edge-systemen leggen beperkingen op die de meeste algemene AI-implementatiepatronen uitsluiten. Hieronder de technische beperkingen die elke edge-AI-implementatie in een automotive- of industriële veiligheidscontext bepalen, en de toolchain-keuzes die ze aanpakken.
Automotive-veiligheidssystemen vereisen doorgaans een end-to-end-latentie onder de 10–50ms. Industriële regelkringen kunnen krapper zijn: 1–10ms voor harde realtimefuncties. Edge-AI-inferentie moet worden geprofileerd op de worstcase-latentie (99e percentiel), niet op de gemiddelde latentie, tegen de beschikbare timingmarge.
Veiligheidskritische edge-systemen mogen voor realtime-inferentie niet afhankelijk zijn van cloudconnectiviteit. De cloud kan worden gebruikt voor modeltraining, monitoring en orkestratie van over-the-air-updates, maar het inferentiepad moet volledig offline functioneren. Netwerkpartities zijn een ontwerpvoorwaarde, geen randgeval.
Automotive-ECU's en industriële PLC's/edge-controllers draaien doorgaans op ARM Cortex-M/R- of RISC-V-kernen met 256KB–4MB RAM. Volledige deep-learningmodellen passen er niet in. Technieken: INT8-kwantisatie (TensorFlow Lite Micro, ONNX Runtime voor MCU's), gestructureerde pruning, kennisdistillatie naar kleinere architecturen (MobileNet, EfficientNet-Lite, op maat gemaakte CNN's).
Het dominante productie-implementatiepad voor edge-AI in beperkte omgevingen: trainen in PyTorch → exporteren naar ONNX → optimaliseren met TensorRT (NVIDIA Jetson / Drive) of ONNX Runtime met XNNPACK/NNAPI-delegate (ARM-SoC). ONNX Runtime ondersteunt ook MCU-implementatie via ONNX Runtime for Microcontrollers. Deze toolchains hebben gedocumenteerd gedrag dat in het veiligheidsdossier moet worden gevalideerd.
Veiligheidssystemen vereisen dat dezelfde invoer altijd dezelfde uitvoer oplevert. Dit vereist: vastekommarekenkunde (INT8 in plaats van FP32), uitgeschakelde runtime-optimalisaties die per uitvoering variëren, vaste threadaffiniteit, geen dynamische geheugenallocatie tijdens inferentie. Bit-exact determinisme over alle implementaties heen bereiken vereist een zorgvuldige toolchain-configuratie en hardwarevalidatie.
Edge-veiligheidscontrollers hebben vaste geheugenenveloppen — vaak niet meer dan 4–16MB Flash en 1–4MB RAM gedeeld over de hele toepassing. Vermogensbudgetten op batterijgevoede of thermisch beperkte apparaten beperken de inferentiefrequentie. Modelkwantisatie en geplande (in plaats van continue) inferentie zijn gangbare oplossingen.
Physical AI-implementatie
Edge-AI-architectuur en embedded inferentie-toolchain voor veiligheidsnabije systemen
Domain Expert LLM Lab
Pipelines voor modeltraining, kwantisatie en validatie voor beperkte hardware
Soeverein LLM (publieke sector)
Air-gapped AI voor kritieke infrastructuur en geclassificeerde omgevingen
Het volgende is een feitelijk verslag van de achtergrond van Hyperion zoals die zich verhoudt tot edge-AI in veiligheidskritische systemen. Dit zijn geverifieerde feiten, geen marketingclaims.
Scope-bekendmaking: Hyperion is een adviesbureau voor AI- en edge-architectuur. Wij adviseren over de AI-/edge-laag — architectuur, toolchain-selectie, ontwerp van de veiligheidsmonitor, ODD-definitie, structuur van het bewijspakket. Wij zijn geen certificeringsinstantie, geen aangemelde instantie en geen geaccrediteerde veiligheidsbeoordelaar. Wij geven geen ASIL- of SIL-certificeringen uit. Formeel certificeringswerk vereist een geaccrediteerde derde partij.
Oprichter Mohammed Cherifi bracht 17+ jaar door in automotive- en embedded-systemen-engineering, onder meer bij Renault-Nissan-Mitsubishi Alliance, Cisco en ABB. Deze achtergrond omvat directe blootstelling aan processen voor functionele veiligheid in voertuigsoftwareontwikkeling, embedded besturingssystemen en de operationele beperkingen van veiligheidskritische omgevingen. Hyperion brengt deze ervaring naar de AI-/edge-laag — niet als certificeringsinstantie, maar als een engineeringteam dat de omgeving begrijpt.
Hyperions vlaggenschip-venture, Auralink, is een aan de edge ingezet agentplatform gebouwd op 400+ microservices met ongeveer 20 AI-agents. De architectuur van Auralink demonstreert de engineeringpatronen die vereist zijn voor AI-inferentie op beperkte edge-hardware — inferentiepaden met lage latentie, deterministische besturingsgrenzen en scheiding tussen de adviserende AI-laag en de gezaghebbende besturingslaag. Dit is overdraagbaar bewijs van de architecturale discipline die vereist is voor veiligheidsnabije edge-AI, en geen veiligheidscertificering.
De physical-ai-deployment-dienst van Hyperion omvat edge-AI-architectuur, selectie van de embedded inferentie-toolchain en de integratielaag tussen AI-inferentie en OT-/embedded besturingssystemen. Onze rol is de AI- en edge-architectuurlaag. Wij adviseren over waar ML-componenten passen binnen een veiligheidsarchitectuur, hoe je de veiligheidsmonitor en het terugvalpad structureert, en welke toolchains geschikt zijn voor de hardware. Wij zijn geen certificeringsinstantie en geven geen ASIL/SIL-certificeringen uit — dat werk vereist een aangemelde instantie.
Een op arXiv gepubliceerde preprint behandelt autonome, aan de edge ingezette AI-agents voor fysieke infrastructuur. Dit is academisch-nabij werk — een preprint, geen peer-reviewed tijdschriftpublicatie — maar het weerspiegelt de architecturale diepgang die Hyperion toepast op edge-AI-implementaties in fysieke systemen.
Mohammed Cherifi bezit de titel AI-ambassadeur van het Osez l'IA-programma van de Franse overheid en is erkend door FranceNum. Dit weerspiegelt betrokkenheid bij AI-beleid en de regelgevende uitdagingen van het inzetten van AI in gereguleerde industriële en automotive-omgevingen.
Niet als enige veiligheidsfunctie — niet met de huidige methodologie en de acceptatieposities van de meeste certificeringsinstanties. De standaardaanpak is om de ML-component op een lager ASIL/SIL-niveau in te zetten (bijv. ASIL B of QM), waarbij een deterministische veiligheidsmonitor die op het hogere niveau is gecertificeerd het verschil overbrugt via ASIL-decompositie. Het totale systeem kan dan voldoen aan ASIL D, maar de ML-component zelf draagt die aanduiding niet. Deze positie weerspiegelt de huidige richtlijnen van ISO 26262-6:2018 en IEC TR 63069:2019 — ze zal evolueren naarmate de normalisatie-instellingen ML-specifieke richtlijnen ontwikkelen (ISO/TR 4804, ISO 8800).
SOTIF (Safety of the Intended Function), gepubliceerd als ISO 21448:2022, behandelt gevaren die niet voortkomen uit systeemstoringen maar uit de beperkingen van de beoogde functie zelf — perceptiehiaten, onverwachte omgevingsomstandigheden en gedrag aan ODD-grenzen. ISO 26262 dekt storingen van het systeem ten opzichte van zijn specificatie. SOTIF dekt tekortkomingen in de specificatie zelf. Voor ADAS- en autonome functies gelden beide normen: je moet zowel aantonen dat het systeem veilig faalt (ISO 26262) als dat zijn beoogde gedrag veilig is over de volledige ODD (SOTIF/ISO 21448).
Een veiligheidsmonitor is een deterministische, onafhankelijk geverifieerde software- of hardwarecomponent die parallel aan de ML-component draait. Hij controleert de ML-uitvoer tegen een set formele veiligheidsbeperkingen — fysieke limieten, grenzen aan veranderingssnelheid, consistentie met sensordata — en blokkeert of overrulet elke uitvoer die deze beperkingen schendt. De veiligheidsmonitor wordt onafhankelijk van het ML-model gecertificeerd op het vereiste ASIL/SIL-niveau. Deze scheiding is het belangrijkste architectuurpatroon voor het inzetten van ML in veiligheidskritische systemen: de ML-component is adviserend, de monitor is gezaghebbend.
De ODD definieert de specifieke omstandigheden waaronder het ML-systeem geldig is: omgevingsparameters (temperatuur, belichting, weer), kenmerken van invoerdata (sensorbereiken, dataformaten, signaalkwaliteit), bedrijfstoestanden van het voertuig of de machine, en geografische of toepassingsspecifieke beperkingen. Elke invoer die buiten de ODD valt, mag niet door de ML-component worden verwerkt — het systeem moet overschakelen naar een terugvaltoestand. Het definiëren, valideren en bewaken van de ODD-grens is een van de belangrijkste engineeringtaken in een veiligheidskritische ML-implementatie.
IEC 62443 definieert een zone-en-conduit-model voor industriële cyberbeveiliging. AI-inferentieservers moeten, net als elk IT-asset, in de juiste zone worden geplaatst (doorgaans Zone 3 — Supervisie) en alle communicatie met Zone 2 (Besturing) moet via een conduit met gedefinieerde beveiligingsmaatregelen verlopen: authenticatie, versleuteling, verificatie van berichtintegriteit. Het inzetten van een AI-inferentieserver die rechtstreeks met PLC's of veldapparaten communiceert zonder conduit-maatregelen schendt het zonemodel. De AI-server zelf moet voldoen aan de Security Level (SL)-eisen voor zijn zone, inclusief patchbeheer, authenticatie en auditlogging.
Er is geen enkele lijst van geaccepteerde configuraties — het hangt af van het beoogde ASIL/SIL-niveau, de certificeringsinstantie en de specifieke use case. In het algemeen: met TensorRT geoptimaliseerde modellen op NVIDIA Drive/Jetson-platforms worden breed gebruikt in ADAS-programma's tot ASIL B, met runtime-assurance-monitors. ONNX Runtime op ARM-SoC's wordt gebruikt in industriële toepassingen op SIL 1–2. Voor hogere integriteitsniveaus kan een formele kwalificatie van de inferentie-runtime zelf (toolkwalificatie onder ISO 26262-8) vereist zijn. Hyperion adviseert over toolchain-selectie en kwalificatiestrategie — het formele kwalificatiewerk vereist betrokkenheid van de toolchain-leverancier.
Nee. Hyperion is een adviesbureau voor AI- en edge-architectuur. Wij adviseren over waar ML-componenten passen binnen veiligheidsarchitecturen, hoe je veiligheidsmonitors en terugvalpaden structureert, welke edge-toolchains geschikt zijn voor beperkte hardware en hoe je implementaties ontwerpt die verenigbaar zijn met de eisen voor functionele veiligheid en IEC 62443. De feitelijke ASIL/SIL-certificeringsbeoordelingen — het conformiteitsbeoordelingswerk dat een certificaat oplevert — moeten worden uitgevoerd door een geaccrediteerde derde beoordelaar of aangemelde instantie. Hyperion kan je helpen die beoordeling voor te bereiden en de architectuur zo te ontwerpen dat ze haalbaar wordt, maar wij geven geen certificeringen uit.
Functionele veiligheid (ISO 26262, IEC 61508) vraagt: faalt het systeem veilig? Ze richt zich op hardware- en softwarefaalwijzen, fouttolerantie en de integriteit van veiligheidsfuncties wanneer componenten falen. IEC 62443 vraagt: is het systeem beschermd tegen opzettelijke aanvallen? Ze richt zich op cyberbeveiligingsmaatregelen — authenticatie, versleuteling, netwerksegmentatie, kwetsbaarheidsbeheer. Beide zijn vereist voor industriële AI-systemen: een systeem kan functioneel veilig zijn (het faalt gracieus) maar cyberbeveiligingstechnisch kwetsbaar (het kan worden aangevallen en tot falen worden gebracht). Specifiek voor AI-systemen zijn adversariële aanvallen een overlappunt — een opzettelijk adversariële invoer kan onveilig ML-gedrag veroorzaken dat een beoordeling van functionele veiligheid alleen niet aan het licht zou brengen.
ISO 26262:2018 (2018). "Road vehicles — Functional safety (Parts 1–12)."
Context: De primaire norm voor functionele veiligheid in automotive. Deel 6 dekt eisen voor softwareontwikkeling, waaronder ASIL-specifieke structurele dekkingsmetrieken. Deel 10 bevat richtlijnen over AI-/ML-componenten (niet-normatief op het moment van publicatie, evoluerend in latere edities).
ISO 21448:2022 (2022). "Road vehicles — Safety of the intended functionality (SOTIF)."
Context: Behandelt gevaren door functionele tekortkomingen in de specificatie of prestatie van de beoogde functionaliteit, waaronder sensorbeperkingen en ODD-grensgedrag in ADAS- en autonome rijsystemen.
ISO/TR 4804:2020 (2020). "Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation."
Context: Technisch rapport met richtlijnen voor het combineren van analyse van functionele veiligheid en cyberbeveiliging voor geautomatiseerd rijden. Dekt SOTIF, ISO 26262 en kruisverwijzingen naar SAE J3061.
IEC 61508:2010 (2010). "Functional safety of electrical/electronic/programmable electronic safety-related systems (Parts 1–7)."
Context: De generieke internationale norm voor functionele veiligheid van E/E/PE-systemen. Definieert SIL 1–4, de faalkans op aanvraag (PFD) en eisen voor softwareontwikkeling en -validatie.
IEC 62443 Series (2018–2024). "Industrial automation and control systems — Security."
Context: Meerdelige norm over cyberbeveiliging voor operationele technologie. IEC 62443-3-3 definieert Security Levels (SL) en het zone-/conduit-model. IEC 62443-4-2 dekt beveiligingseisen voor componenten die van toepassing zijn op AI-inferentieservers in OT-netwerken.
IEC TR 63069:2019 (2019). "Industrial-process measurement, control and automation — Framework for functional safety and security."
Context: Technisch rapport over de relatie tussen functionele veiligheid (IEC 61508) en cyberbeveiliging (IEC 62443). Direct relevant voor AI-implementaties die beide domeinen omspannen.
UL 4600:2020 (2020). "Standard for Safety for the Evaluation of Autonomous Products."
Context: Eerste uitgebreide norm die zich specifiek richt op ML-gebaseerde autonome systemen. Dekt het opbouwen van het veiligheidsdossier, de ODD-definitie, operationele bewaking en runtime assurance voor ML-componenten. Breed gerefereerd in Noord-Amerikaanse automotive-programma's.
ISO/IEC TR 24029-2:2023 (2023). "Artificial Intelligence — Assessment of the robustness of neural networks — Part 2: Methodology for use in formal methods."
Context: Biedt richtlijnen over methodologieën voor robuustheidstests voor neurale netwerken, waaronder adversariële robuustheid — relevant voor zowel functionele veiligheid als IEC 62443-cyberbeveiligingsanalyse.
Veiligheidskritische ML-implementaties vereisen meer dan goede modelprestaties — ze vragen om een verdedigbare architectuur, de juiste toolchain voor de hardwarebeperkingen en een gedocumenteerd veiligheidsdossier dat een certificeringsinstantie kan accepteren. Hyperion brengt 17+ jaar ervaring in automotive- en embedded-systemen-engineering naar de AI-/edge-laag. Wij adviseren over architectuur en bewijsstrategie; de formele certificering blijft bij de bevoegde geaccrediteerde instantie. Begin met een gerichte architectuurreview.
Oprichter & Hoofd AI-strategie
Mohammed Cherifi is de oprichter van Hyperion Consulting, met 17+ jaar in automotive- en embedded-systemen-engineering. Hij heeft gewerkt bij Renault-Nissan-Mitsubishi Alliance, Cisco en ABB — omgevingen waar processen voor functionele veiligheid de softwareontwikkeling reguleren. Hij is gespecialiseerd in edge-AI-architectuur voor fysieke systemen, waaronder veiligheidsnabije implementaties in automotive- en industriële OT-omgevingen.
Edge-AI-architectuur en embedded inferentie voor fysieke systemen
Van simulatie naar productie-implementatie in productierobotica
Soevereine, air-gapped AI-implementatie voor industriële omgevingen
De 6-laags Physical AI Stack voor robotica, edge-AI en industriële automatisering