Les pneus à plat sont une réalité de la vie, qu'il y ait un humain derrière le volant ou non. Pour les véhicules autonomes (VA) fonctionnant comme des voitures sur la route, un exemple hypothétique à grande échelle pourrait ressembler à ceci : Un seul véhicule roulant pendant une heure n'a qu'une chance sur un million d'avoir une crevaison, mais pour 10 000 AV, cela pourrait représenter une chance sur deux d'avoir un pneu crevé toutes les deux semaines quelque part dans la flotte. Pourquoi ? Le temps + l'échelle = plus de risques.

Tous les systèmes autonomes comportent intrinsèquement des risques parce qu'il s'agit de machines, et que les machines peuvent mal fonctionner. Ces types de systèmes comprennent à la fois du matériel et des logiciels, ce qui entraîne un niveau de complexité élevé. C'est pourquoi les constructeurs doivent analyser soigneusement les risques associés aux différentes fonctions du système. Certaines machines étant plus dangereuses que d'autres, les différents types de systèmes doivent être conçus de manière à atteindre le niveau de réduction des risques approprié à leur application. Il est clair qu'un système conçu pour des voitures autonomes ou des avions de ligne devrait avoir une désignation de sécurité plus élevée qu'un petit aspirateur robotisé domestique.

Bien que les robots mobiles autonomes (AMR) de Brain Corp se déplacent beaucoup plus lentement que les AV et soient moins susceptibles de causer des blessures, ils doivent en réalité opérer à proximité de personnes dans des espaces restreints. Et contrairement aux AV d'aujourd'hui, les AMR alimentés par BrainOS fonctionnent déjà à grande échelle sans qu'une personne soit immédiatement présente pour prendre le contrôle par le biais d'une commande manuelle. C'est pourquoi Brain Corp suit un processus rigoureux et systématique de planification de la sécurité.

Plus qu'un attribut du produit, la sécurité est un processus. Pour mettre sur le marché des machines qui affichent un comportement sûr et fiable, comme les AMR alimentés par BrainOS, les constructeurs doivent suivre les étapes suivantes.

1. Évaluer les risques

Identifier les dangers et les risques pour quantifier la fiabilité d'un système de sécurité. Il s'agit de comprendre les fonctions de sécurité critiques et de classer les risques en fonction de leur gravité et de leur probabilité afin d'allouer les ressources de manière appropriée. Ils doivent également prendre en compte tous les risques potentiels posés par l'environnement dans lequel un système fonctionnera. Il s'agit d'une évaluation particulièrement importante et difficile pour les nouvelles formes de robotique telles que les AMR, d'où l'importance d'une saisie maximale des données et d'une évaluation continue.

2. Définir et documenter les besoins

Déterminer les fonctions qui assureront la protection contre les risques et les dangers identifiés, et les documenter clairement de manière à ce que les tests ultérieurs puissent être mis en correspondance directement avec les exigences de manière transparente.

3. Concevoir et analyser l'architecture du système

Effectuer une analyse probabiliste des défaillances du système et définir les principaux composants de sécurité critiques et le flux d'informations dans l'architecture du système. Concevoir une redondance dans le matériel et le microprogramme du système en cas de défaillance partielle. À titre d'exemple, le système approuvé par Brain Corp pour les AMR comprend à la fois le système de navigation principal et un système indépendant basé sur un microcontrôleur qui sert de sauvegarde. Pour les AMR, trois sous-systèmes critiques doivent être analysés : la détection des obstacles, la détection des falaises et le contrôle de la vitesse.

4. Introduire le code de sécurité

Mettre à jour le matériel et les logiciels avec des diagnostics d'autocontrôle. Le matériel doit répondre à des objectifs de fiabilité quantifiés pour les modes de défaillance et leurs effets. Évaluer les modes de défaillance de chaque composant de la fonction de sécurité, ainsi que l'impact et la probabilité de chaque type de défaillance. Concevoir des logiciels selon des ensembles de règles qui minimisent les comportements indéterministes.

5. Valider

Tester et analyser tous les composants individuels et les systèmes intégrés. Tous les codes de sécurité doivent être soumis à des tests d'injection de fautes et le code source doit être analysé pour détecter les violations de règles. Une fois que le matériel et le logiciel sont combinés sur un véhicule, une équipe d'assurance qualité doit effectuer des tests fonctionnels pour voir comment le système fonctionne dans des scénarios réels.

6. Contrôler et mettre à jour

Effectuer un contrôle continu, en utilisant des données et une gestion de flotte basée sur l'informatique en nuage. Les organisations doivent observer et documenter en permanence les performances d'un système tout au long de son cycle de vie afin de faire face aux risques dès qu'ils apparaissent. Les informations tirées des données enregistrées sont utilisées pour améliorer le système.

Aujourd'hui, alors que de plus en plus d'AMR sont déployés pour aider au nettoyage et à la désinfection pendant la crise de santé publique COVID-19, la sécurité est plus importante que jamais. En fait, il s'agit d'une priorité absolue de Brain Corp, et c'est pourquoi notre processus de sécurité est si complet. Le résultat est que les machines sont capables d'être fiables et sûres à grande échelle au fil du temps. Le marché de l'AMR n'en est qu'à ses débuts, il aura donc besoin d'un engagement continu pour parvenir à une application cohérente des processus de sécurité au fur et à mesure qu'il se développera. Brain Corp s'engage à travailler avec ses partenaires sur la sécurité des machines et continuera à mener l'industrie dans la planification de la sécurité.