n° 219
Novembre 2017
Dicembre 12, 2017, 06:42:46 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
Notizia:
 
   Indice   Linux Windows Techassistance Gameassistance videogame hardware Aiuto Ricerca Agenda Downloads Accedi Registrati  


* Messaggi recenti
Messaggi recenti
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: 03) Il meraviglioso mondo dei sistemi embedded  (Letto 5501 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« inserita:: Maggio 09, 2008, 02:55:16 »

Q: Perché in giro leggo tutto e il contrario di tutto riguardo ai sistemi embedded ?
Come mai questa etichetta sembra poter essere appiccicata liberamente a qualsiasi aggeggio elettronico che non sia un PC, dal rasoio elettrico alla Stazione Spaziale Internazionale ?
In definitiva, quali e quanti tipi diversi di sistemi embedded vengono classificati dagli specialisti ?


A: Stante la enorme varietà dei sistemi embedded, è noiosamente ovvio che sia possibile classificarli in molti e diversi modi, più o meno arbitrari e limitati dalla specifica visione di chi, di volta in volta, si appresta a classificare in modo complessivo un mondo che però - di norma - conosce solo parzialmente.

Una delle classificazioni macroscopiche maggiormente diffuse tra i practitioners è la tassonomia basata sulla criticità di applicazioni e sistemi. Tale approccio qualitativo (che peraltro sottende metriche oggettive di rischio, come ad esempio le classi di sicurezza SIL della norma IEC 61508) risulta particolarmente valido, poiché molti sono i parametri caratteristici dei sistemi embedded che seguono concordemente l'andamento della criticità: in particolare, citerei la complessità e la robustezza, nelle loro varie accezioni ingegneristiche e quantificabili, con le relative variabili di costo NRE(1), costi di produzione e conseguenti economie di scala.

In prima approssimazione, ed escludendo per ovvie ragioni gli apparati mobile che non sono sistemi embedded in senso proprio, è possibile individuare tre distinte aree:

1) Sistemi non critici: consumer embedded, piccoli elettrodomestici, gadget...
2) Sistemi loss-sensitive: network appliances, TLC, accettori banconote e ATM, distributori automatici...
3) Sistemi safety- e life-critical: aerospaziale e avionica, petrolchimico, energetico e nucleare, militare, biomedicale, controllori del traffico, impianti a ciclo continuo...

Vale la pena di notare che, procedendo in ordine crescente nella scala della cricità, i sistemi diventano anche via via meno adatti ad una industrializzazione massiva, e sempre più concettualmente simili alle opere "uniche" delle discipline classiche dell'ingegneria (strade e viadotti, piping, edifici, navi...).

Riassumiamo e giustifichiamo brevemente le caratteristiche di questa suddivisione arbitraria, largamente accettata dalla letteratura e dalla comunità dei practitioners, limitandoci agli aspetti qualitativi più macroscopici.

1) Sistemi non critici
Sintetizzando al massimo, sono sistemi embedded consumer classificati come non critici la maggior parte degli elettrodomestici moderni, che abbiano una qualsiasi interfaccia ed un minimo di programmabilità da parte dell'utente e, soprattutto, che contengano qualche sorta di microprocessore o microcontroller. Simili sistemi sono definiti sbrigativamente "white goods" nella letteratura anglosassone, a causa del colore predominante dello chassis. Allo stesso modo, fanno parte della categoria piccoli automatismi industriali, sistemi civili per comunicazione e automazione domotica, networking SOHO, e molto altro.
Perché sono considerati acritici? In caso di malfunzionamento o guasto, il danno possibilmente prodotto all'ambiente ed alle persone è praticamente irrilevante: spesso perfino impercettibile.


2) Sistemi loss-sensitive
I sistemi ascritti a questa categoria, come suggerisce l'espressione, possono già causare a singole entità private o commerciali un danno economico rilevante in caso di mancato funzionamento o interruzione del servizio.

Questi apparati e le loro applicazioni presentano quindi caratteristiche che li rendono dissimili dai prodotti consumer: ad esempio, se si accetta di includere tra i sistemi embedded propriamente detti anche gli appliance di rete (la discussione in merito è ancora aperta nella comunità degli esperti), il blocco di un router non ridondato, o anche un semplice crollo di prestazioni per un bug software, può comportare un grave danno economico, limitatamente al caso di siti e-commerce molto frequentati. La criticità dipende ovviamente dall'applicazione.

Lo stesso si applica anche ai sistemi con accettazione di moneta e credit/debt media: un distributore non funzionante comporta chiaramente un danno, sotto forma di mancato introito potenziale per il suo gestore. Per tacere del caso di rimanere intrappolati in un parcheggio a pagamento, o appiedati perché non si riesce ad introdurre la somma richiesta a causa di un guasto!

Questi sistemi, quindi, possono essere un po' più critici dal punto di vista prestazionale ed economico rispetto ai già visti apparati consumer, e richiedono, di conseguenza, particolare cura e specifici accorgimenti progettuali ed implementativi.


3) Sistemi safety- e life-critical
Qualche lettore sarà forse sorpreso di apprendere che in una moderna autovettura sono installati almeno due dozzine di microprocessori e microcontroller che presiedono a funzioni vitali (dalla gestione della centralina di iniezione, all'impianto frenante, all'ABS) ed anche secondarie (dalla regolazione del comfort dei passeggeri, alla climatizzazione, al GPS, al sistema antifurto...).

E' dunque intuitivo ed immediato rendersi conto che il livello di criticità di un apparato embedded automotive, ciò di cui stiamo parlando, è decisamente diverso da quelli sopra esaminati: è sufficiente pensare alle possibili conseguenze di un eventuale guasto improvviso.

In questa classe di sistemi il fallimento è semplicemente inaccettabile, e vengono utilizzati tutti i migliori strumenti in nostro possesso per ottenere il massimo grado di confidenza nella robustezza del sistema, anche tramite dimostrazioni formali di correttezza - pratica del tutto sconosciuta in altri settori software.

Le caratteristiche di robustezza e affidabilità vengono ottenute tramite una accurata sovrapposizione di scelte progettuali sicure, a partire della meccanica del sistema, passando all'hardware, fino alle procedure software, in un procedimento di codesign (progettazione contemporanea e parallela di architettura distribuita, reti di comunicazione, hardware, firmware, software) ricorrendo a strumenti a loro volta certificati ed a tutti i metodi formali capaci di garantire l'assenza di errori significativi e la resistenza del sistema in condizioni estreme, spesso anche in caso di errore umano, calamità naturale e perfino tentativi di sabotaggio. Il tutto senza trascurare l'aspetto dei costi finali, che in molti settori (tra questi, appunto, l'automotive) è fondamentale.

Da questa classe di sistemi in poi, l'embedded critico somiglia sempre più ad un campo minato, con complessità e rischi sempre crescenti, fino a giungere al top dell'applicazione critica, tipicamente identificato nei complessi sistemi di controllo ridondanti applicati nelle raffinerie, negli ambienti a rischio d'esplosione in genere, nelle centrali nucleari, nelle missioni spaziali con personale umano o cavie animali, nei sistemi diagnostici, terapeutici e per il mantenimento artificiale delle condizioni vitali impiegati negli ospedali, nel controllo del traffico aereo, nei sistemi d'arma e militari in genere.

Lo sviluppo e l'engineering di tali sistemi, ben lungi dal lassismo e dall'improvvisazione che imperano in molti settori mainstream, è regolato da rigorose normative tecniche internazionali, alle quali sono connessi sia obblighi legislativi in recepimento (norme cogenti), sia certificazioni selettive e di altissimo profilo rilasciate da Enti internazionali. Ecco alcuni esempi:

RTCA DO-178/C, la più rigorosa norma attualmente in vigore, per applicazioni avioniche ed equivalenti, con tutte le norme connesse, come DO-278/A e soprattutto DO-333 (appendice dedicata specificamente ai metodi formali) e l'intero set delle specifiche ARINC, in particolare la 653 (Avionics Application Standard Software Interface);

EN 60880 per il nucleare e l'energetica, con le sue varie emanazioni subordinate (es. EN 61850);

MIL-STD-498, ovviamente di natura militare;

ESA PSS05 per l'aerospaziale;

EN 61508 sicurezza funzionale industriale e generale, con le sue numerose derivate (es. EN 61511 per l'industria di processo, EN 60601 per l'elettromedicale, EN 61131 ed EN 61499 rispettivamente per il magico e variopinto mondo dei PLC e dell'automazione distribuita...);

EN 50128 (software), EN 50126 (Specification and Demonstration of Reliability, Availability, Maintainability and Safety: RAMS), EN 50129 ed EN 50159 (safety, communications) specifiche per il ferroviario, in sostanza l'intera famiglia delle EN 5012x entro il quadro generale della norma EN 50155;

ISO 26262 e in particolare lo standard di codifica MISRA/C specifico per il mondo automotive;

IEC 62304 e FDA-21 CFR come base per il biomedicale.


(1) Non-Recurrent Engineering costs: costi di sviluppo, engineering, industrializzazione... tutto ciò che, nella vita di un prodotto, incide "una sola volta" e "all'inizio dello sviluppo" nell'asse dei costi, ovvero non rientra nei costi ciclici di produzione industriale e manutenzione/affinamento. Tali costi, di norma, sono anche del tutto svincolati dalle quantità prodotte.

(2) Caratteristiche essenziali che distinguono il firmware dal software sono le seguenti:
a) Il firmware risiede su silicio, ossia su memorie non volatili di tipo ROM, PROM, EPROM, E2PROM, Flash E2PROM, FRAM, NVRAM, al limite anche le classiche RAM statiche tamponate a batteria. Nel caso dei microcontroller (MCU) e System-on-Chip (SoC), tali memorie sono tipicamente integrate su un unico die di silicio con il core che esegue il firmware stesso;
b) Il firmware usualmente non è riscrivibile "on the fly". Questa era LA peculiarità che distingueva il firmware dal resto del software fino agli anni Novanta, con l'ovvia (e inerentemente poco affidabile) eccezione delle memorie RAM con batteria tampone: in quei tempi gloriosi si diceva firmware, sic et simpliciter, tutto il software che risiedeva su ROM o EPROM.
La recente moda generale (non sempre motivata da stringenti necessità) di impiegare memorie Electrically Erasable come program memory - cancellabili e riprogrammabili direttamente in-circuit, sovente senza tensioni ausiliarie, seppure in tempi non trascurabili - ha reso meno netta questa linea di demarcazione concettuale, un tempo dirimente in assoluto;
c) Il firmware, di fatto, forma un unicum con l'hardware controllato. Durante la normale operatività, nel caso medio, non è usualmente prevista per il firmware alcuna operazione esplicita di "caricamento", attivazione, selezione da parte dell'utente finale.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
Pagine: [1]   Vai su
  Stampa  
 
Vai a:  

Copyright © 2017 Edizioni Master SpA. p.iva : 02105820787

Tutti i diritti di proprietà letteraria e artistica riservati. - Privacy



powered by Simple Machines