Origini di Java e caratteristiche utili nel campo dei sistemi embedded

Narra la leggenda che Java nasce nell’ambito di un grande progetto per la creazione di una vasta gamma di device di rete e sistemi embedded; il linguaggio inizialmente scelto era il C++, ma le difficoltà incontrate dagli svilupattori furono tali da convincerli che, a conti fatti, sarebbe stato più redditizio creare un nuovo linguaggio già pensato per affrontare le problematiche rivelatesi tanto ostiche.

Il risultato: qualcosa a metà strada tra un sistema operativo ed un linguaggio semi-interpretato ma con alcune caratteristiche determinanti:

  • Sintassi familiare: chi già conosce il C ed un po’ di C++ necessita di pochi giorni di training per raggiungere un’operatività di base con Java.

Run time system sufficientemente piccolo da potere essere adottato nei sistemi embedded (inizialmente: 40 K per l’interprete e 175 k per le librerie di base ed il supporto ai thread).

Portabilità del codice, che può così essere trasmesso via rete tra device diversi rimanendo egualmente eseguibile ovunque. Le classi possono poi essere caricate dinamicamente, anche via rete, senza bisogno di restart dei dispositivi, particolarità non trascurabile quando si parla di delicati impianti industriali o militari, i cui i costi (ed i rischi) di fermo possono essere ordini di grandezza superiori di quelli relativi allo stesso software.

Se pensiamo che in qualsiasi laboratorio di sistemi embedded si lavora con processori diversi, spesso contemporaneamente presenti nello stesso apparato, la riduzione dei costi di training, di gestione delle versioni e, in generale, del time to market apportata dall’uso di un unico linguaggio può rivelarsi un fattore determinante di successo commerciale. Inoltre, ed è spesso una regola, lo sviluppo del software avviene parallelamente a quello dei dispositivi fisici: questo richiede sforzi aggiuntivi per la creazione di simulatori e dei successivi adattamenti al sistema definitivo. Un programma Java, invece, viene eseguito dalla propria JVM sia su un personal computer che su una scheda custom, con differenze limitate ai tempi d’esecuzione (particolare questo, come vedremo, tutt’altro che trascurabile).

Possibilità di compilazione al volo sui diversi dispositivi per raggiungere performance comparabili a quelle del codice C++.

Abolizione dei puntatori e della necessità di ripulire la memoria non più referenziata: in altre parole, eliminazione delle due principali cause di errore in programmi di grosse dimensioni.

Semplificazione nell’implementare sistemi fault-tollerant: in caso di guasto o di sovraccarico di un device, il suo programma può essere ridistribuito in modo sufficientemente trasparente sugli altri componenti, anche con hardware e processori diversi.

Classi standard per il networking e per l’esecuzione di oggetti distribuiti. Nel moderno software industriale, le problematiche di comunicazione ed integrazione tra apparati superano sempre più di frequente quelle di elaborazione e controllo: i vari processori di un’automobile di classe alta comunicano tra loro con una vera e propria rete locale; il software di supervisione e controllo di processi industriali è sempre più integrato con gli altri sistemi aziendali, dal management alla logistica.

Tutte queste doti costituiscono, di per sé, un motivo sufficiente per destare l’interesse di chiunque produca software professionale di qualsiasi tipo.

Non deve quindi stupire che anche settori come quelli dei sistemi embedded e real-time, tradizionalmente dominio dell’assembler o, al massimo, del linguaggio C, stiano cercando in Java una possibile alternativa, almeno per certe applicazioni.

È forse proprio in questo campo che sono attesi a breve termine gli sviluppi più interessanti, con l’arrivo dei primi CHIP con la Java Virtual Machine implementata in silicio e quando gli accordi della SUN con grossi produttori di sistemi embedded porteranno ai primi PLC programmabili in Java e le JavaCard, telefoniche o personali, diventeranno una realtà quotidiana così come i televisori integrati con la grande rete.

Un modello per i sistemi real-time

Partiamo da una definizione:

chiameremo sistema real-time qualsiasi insieme HW/SW dove uno o più componenti devono essere eseguiti entro precisi limiti di tempo per ottenere un corretto funzionamento (cioè la capacita di svolgere in modo utile e corretto il lavoro per cui il componente e l’intero sistema sono stati progettati).

Questa mia definizione non è formale e, noteranno i più esperti, nemmeno troppo precisa. Tuttavia essa vuole sottolineare due aspetti importanti:

  • Non tutti i componenti si un sistema RT sono dipendenti dal tempo.

Un task RT può venire eseguito senza errori rispetto alle asserzioni sui dati in I/O eppure non essere funzionalmente corretto: se il task che regola la frenata nel nostro ABS riesce a calcolare esattamente la proporzione di frenata per ogni ruota ma, per questo lavoro, impiega ½ secondo in più dei limiti in specifica, potremmo esserne molto contrariati!! Anche la scusante che nello stesso momento la CPU della centralina di controllo fosse impegnata nel bel mezzo del complesso ricalcolo della percentuale d’aria da usare nella carburazione potrebbe non risultare consolante.

Un buon modello per i sistemi RT, che ben si adatta anche alle metodologie più classiche, è il seguente, basato sul lavoro di Kelvin Nielsen, il creatore del PERC, un ambiente Java real-time di cui parleremo in un'altra occasione. Il modello parte da una classificazione dei diversi tipi di task che possono comporre un apparato:

  • Task periodici: sono intrinsecamente dipendenti dal tempo in quanto vengono schedulati ad intervalli fissi (ad esempio Ts=1/1000 sec.) ed il loro tempo massimo di esecuzione (Tme) nel caso peggiore (WCE: Wrost Case Execution) deve necessariamente essere Tme\<Ts. Non sempre il caso Tme~Ts implica la completa occupazione del tempo di CPU dell’intero sistema, anche se monoprocessore, in quanto spesso il tempo tipico d’esecuzione (Tte) è assai inferiore del caso peggiore. Il calcolo del Tme e del suo rapporto con il Tte è una classica problematica dei sistemi real-time.

Task sporadici: schedulati a tempo non predeterminato in risposta ad eventi esterni. Possiamo considerare:

  • Task sporadici normali: senza vincoli di tempo.

Task sporadici RT: la risposta all’evento scatenante deve essere fornita entro un tempo massimo.

Task spontanei: come i task sporadici normali, possono essere eseguiti in un momento qualsiasi in risposta ad un evento o ad un cambiamento di stato del sistema e non hanno vincoli sul tempo di risposta. La particolarità, difficile da mandar giù per chi nei propri programmi ha sempre avuto tempo a disposizione, è che lo scheduler conosce a priori le risorse ed il tempo necessari all’esecuzione del task e lo esegue solo avendo la certezza di avere a sua volta tempo e risorse sufficienti per assicurare il suo completamento. In caso contrario la richiesta d’esecuzione del task viene semplicemente ignorata. Se nell’esempio precedente, relativo alla centralina della nostra macchina, il controllo automatico della carburazione fosse stato un task spontaneo, il nostro ABS avrebbe avuto vita più tranquilla (e noi con lui).

Thread RT ciclici: sono task che girano in un ciclo infinito avanzando il loro stato in proporzione al trascorrere del tempo. La differenza con un normale task ciclico è che il sistema riserva una precisa percentuale di tempo ad un Thread RT garantendone l’avanzamento indipendentemente dal comportamento del resto del sistema. Questo si realizza, di solito, su tempi relativamente lunghi, nell’ordine di vari secondi, in modo che se anche il thread dovesse trovare qualche risorsa occupata, lo scheduler avrebbe comunque tempo da ridistribuire per mantenere la percentuale di CPU contrattata con il task.

Runnable Thread: ovvero i comuni thread, come quelli Java, senza vincoli di tempo.

In questo modello, un programma consiste di un certo numero di attività real-time e di un numero arbitrario di normali thread. La divisione di un programma in più attività real-time, ognuna composta da un qualsiasi numero di task dei tipi suelencati, consente di scegliere politiche di schedulazione differenti per ogni insieme di task relativi ad uno stesso compito. Ogni attività ha assegnata una certa percentuale delle risorse di sistema ed un task può essere bloccato solo da un altro task appartenente alla stessa attività.

Il concetto di priorità di schedulazione di un thread, in un sistema real-time, è molto diverso da un normale programma Java, in quanto esso non ha nulla ha che fare con l’importanza del task. Piuttosto, un thread è tanto più elegibile per l’esecuzione quanto più basso è l’ordine della sua frequenza d’esecuzione.

Altro aspetto importante è la disponibilità di primitive per le transazioni, ovvero per segmenti di codice atomico con la caratteristica del tutto o niente che non possano lasciare il sistema in uno stato incongruente se non completati correttamente. Le transazioni in un ambiente RT devono essere realizzate in modo da non pesare sui vincoli di tempo dei rimanenti thread. Un lock realizzato mediante disabilitazione degli interrupt, ad esempio, è in genere non adatto, a meno che la sua durata non sia calcolata come più breve del jitter (l’indeterminatezza) accettabile dal sistema. Un’implementazione classica richiede la conoscenza, da parte del sistema, del tempo residuo nell’attuale fetta assegnata al task, consentendo l’entrata nel segmento atomico solo se la sua durata è inferiore al tempo residuo; in caso contrario il thread viene sospeso. Altre implementazioni richiedono analisi ancora più dettagliate sull’interazione tra i blocchi dei diversi task per decidere il tempo massimo per cui ognuno può essere sospeso.

Infine, consideriamo il problema dell’accesso dinamico alla memoria nell’ambito di un sistema real-time. I comuni allocatori di memoria hanno il grande problema della frammentazione che costringe ad eseguire dei task dedicati alla ricompattazione della RAM rilasciata. Se poi aggiungiamo un garbage collector che giri anch’esso in modo asincrono otteniamo un marchingegno difficilmente gestibile entro precisi vincoli di tempo. Molti linguaggi ed ambienti di sviluppo per sistemi RT semplicemente non consentono l’allocazione dinamica della memoria. Nei sistemi moderni, ed in particolare sul PERC, non solo è consentita l’allocazione dinamica della memoria, magari con la pulizia automatica, ma anche task ed intere attività possono essere caricate o rimosse in qualsiasi momento provocando una riconfigurazione del sistema che non richiede la sospensione dei task già in esecuzione.

Vi siete spaventati? Non avete torto. Tutto questo lavoro certosino, un tempo, andava fatto a mano o in modo semi-assistito. Bene, un ambiente di sviluppo e d’esecuzione real-time può considerarsi tanto migliore quanto più è in grado di compiere in proprio tutte le analisi sui tempi, i blocchi, le transazioni, l’allocazione ed il rilascio della memoria. Il sistema ideale dovrebbe richiedere la semplice dichiarazione della tipologia dei vari task per ogni attività ed i soli vincoli di tempo verso l’esterno (ad esempio il tempo massimo di risposta dell’attività ABS) e compiere in proprio sia l’analisi statica che il profiling segnalando al programmatore le eventuali impossibilità d’esecuzione e prendendosi cura di far rispettare i contratti che ogni attività o thread stipula con il sistema.

Java ed i sistemi embedded e real-time

Sia chiaro: Java e la sua JVM nelle versioni standard, per quanto nate pensando al software embedded, non sono assolutamente adatti alle applicazioni effettivamente real-time. Questo per diverse ragioni:

  • La garbage collection influisce sul carico generale del sistema in maniera non predicibile e non consente nemmeno una stima dei tempi di ogni singola allocazione. (vedi Computer Programming Feb/98…)

Le politiche di scheduling della CPU non sono pensate per garantire tempi e frequenze d’esecuzione ma, piuttosto, per consentire l’avanzamento di tutti i thread. In altre parole la priorità non è bloccante ed il thread di priorità più elevata tra quelli elegibili all’esecuzione non ha la certezza di avere la CPU a completa disposizione.

La sincronizzazione è realizzata, internamente alla JVM, con un meccanismo semaforico privo di limitazioni: è possibile mantenere indefinitivamente un lock su qualsiasi oggetto e, inoltre, si presenta il problema dell’inversione di priorità. Esempio: un thread ad alta priorità (p=8) deve attendere il rilascio di un lock da parte di un thread di livello inferiore (p=4) che a sua volta aspetta la CPU occupata da un thread con p=6. Sistemi semaforici più sofisticati (p.e. in POSIX) elevano temporaneamente la priorità del thread inferiore a quella del task di rango maggiore che attende su una risorsa da esso bloccata.

Non esistono meccanismi di account della necessità di risorse (tempo e memoria) dei diversi segmenti di codice. Non sono quindi attuabili transazioni. I paradigmi più strettamente real-time comprendono la possibilità di conoscere le risorse disponibili in ogni momento sul sistema ospite e quelle necessarie all’esecuzione di ogni task: in questo modo lo scheduler sceglie di lanciare un task solo nella certezza di poterlo portare a compimento in un tempo limite oppure non lo esegue affatto. In alternativa possono esistere meccanismi di abort su timeout uniti a funzioni di commit che confermano le modifiche allo stato del sistema (variabili ed oggetti nella heap globale) solo al termine dell’esecuzione: un task, in pratica, non lascia traccia della propria esecuzione se questa non viene completata con successo in tempi utili.

L’implementazione di alcune classi standard, come Observable/Observer non è pensata per applicazioni dipendenti dal tempo (vedi dell’Autore "Sotto la foresta di Java", Mokabyte Marzo/98)

Oggetti e thread non sono architetturalmente congruenti. In altre parole non sono realizzabili oggetti vivi che abbinino strettamente un thread all’istanza di una classe. Il paradigma degli oggetti vivi comporta che ogni metodo venga eseguito nell’ambito dell’unico thread dell’oggetto chiamato, piuttosto che in quelli dei vari oggetti chiamanti. Il problema è che ciò richiede modifiche radicali alla specifica delle correnti JVM. La forza di questo paradigma consiste nel non richiedere primitive di sincronizzazione: anche avendo usato Java in ambienti non real-time, tutti ci siamo resi conto che la primitiva synchronized non è affatto così comoda da usare come sembra inizialmente e che i pericoli di blocco critico sono spesso più insidiosi che usando i cari vecchi semafori.

Tutto ciò significa che i progettisti di apparati industriali dovranno rinunciare a tutti i vantaggi di Java a causa delle sue limitazioni? Ovviamente no.

Prima di tutto una grande fetta del software embedded non è effettivamente real-time, basti pensare ai più comuni elettrodomestici, ai telefoni o alle SmartCard.

Figura 1
Figura 1

E invece cosa dire di automobili, impianti industriali, aereoplani, centrali elettriche, satelliti? Che strade stanno prendendo i santoni della SUN e i loro partner del settore? Suonerà strano, trattandosi del linguaggio standard per eccellenza, ma come vedremo le soluzioni attualmente prospettate implicano dialetti, sottoinsiemi (magari senza garbage collection) ed altro ancora.

Tenuta presente la particolarità del settore, non è poi così grave, se le alternative sono C++, C e ancora assembler, e assembler…

Caratteristiche importanti per i sistemi embedded nei principali linguaggi

I voti dati alle caratteristiche dei vari linguaggi potranno indisporre qualcuno: esiste una casta di programmatori che prende il proprio linguaggio preferito come una questione religiosa ed è molto sensibile ai giudizi meno che entusiastici (in maggioranza tali programmatori sono adepti del C++).

Comunque, tanto è! E se non siete daccordo, i voti dateli da soli!!

Ciò che appare lampante dalla seguente tabella (e non deve stupire, data la filosofia di progettazione del linguaggio) è che Java è, a seconda dei casi, o il primo o l'ultimo della classe!

Inizialmente, in effetti, si voleva un linguaggio privo di compromessi, che rinunciasse ad alcune caratteristiche a netto favore di altre. D'altro canto è pur vero che tutta l'attuale ricerca in SUN, JavaSoft e partner è volta ad incrementare le performances là dove sono più precarie, con un occhio di riguardo alla velocità d'esecuzione ed ai tool di sviluppo.

| | Java | C++ | C | Assembler | | --- | --- | --- | --- | --- | | Capacità di Networking | 5 | 4 | 4 | 1 | | Integrazione con Internet/Intranet | 5 | 3 | 3 | 0 | | Ampiezza e standardizzazione delle librerie | 5 | 3 | 3 | 1 | | Portabilità | 5 | 2 | 3 | 0 | | Object Oriented | 4 | 3 | 0 | 0 | | Supporto nativo della concorrenza e primitive di sincronizzazione | 4 | 0 | 0 | 0 | | Semplicità (Leggibilità, corregibilità, velocità nello scrivere codice corretto) | 4 | 2 | 3 | 1 | | Tempi di sviluppo (Codifica e test) | 4 | 3 | 3 | 1 | | Diponibilità di tool di sviluppo e test | 3 | 3 | 4 | 3 | | Necessità di RAM/ROM | 3 | 3 | 4 | 5 | | Velocità di esecuzione | 1 | 3 | 4 | 5 | | Controllo dei tempi d’esecuzione | 0 | 2 | 3 | 5 | | Controllo dei dispositivi (I/O, ISR, etc…) | 0 <br> (3 con native) | 3 | 4 | 5 | | Voti da 0 a 5 | | | | |

Cosa si muove in giro

C’è grande fermento tra le maggiori compagnie di hardware e software, nonché in importanti università e centri di ricerca, ed i numerosi studi stanno già diventando prodotti. Quello che segue è un elenco che, senza la pretesa della completezza, vuole dare un quadro quanto più realistico degli scenari in via di formazione.

Sono sicuro che questa manciata di notizie in libertà potrà destare interesse sia nell’ingegnere di processo, ancora non convinto che Java applicato al software RT sia una possibilità vicina nel tempo, che al normale programmatore rassegnato fino ad ora a sentirsi escluso dal settore e che, adesso, potrà cominciare a guardare al software industriale come un campo con le sue particolarità ma dove, in fondo, si parla la stessa lingua.

Ecco l’elenco. I link forniti per approfondire gli argomenti in proprio puntano, quando possibile, direttamente alle pagine riguardanti il tema trattato nei vari siti:

  • Cominciamo con quanto viene sviluppato in SUN ed in JavaSoft: si tratta, più che di prodotti, di specifiche di standardizzazione destinate a essere tradotte in prodotti da terzi o dalla stessa SUN (la denominazione ufficiale è Programming Interfaces):
- [JavaCard](http://www.javasoft.com/products/javacard/index.html): tutto il necessario per programmare device grandi come una carta di credito (o un anello, un braccialetto…). Destinazione commercio elettronico, controllo di accesso, database personale (in Germania, ad esempio, già si usano delle card per l’accesso alle prestazioni sanitarie). Tra i primi produttori con licenza SUN: [Schlumberger](http://www.schlumberger.com/), [Gemplus](http://www.gemplus.com/), [Bull](http://www.cp8.bull.net/news/021798a.htm) e [Visa](http://www.visa.com/cgi-bin/vee/av/news/PRelco010898.html?2+0). Più recente l’accordo tra SUN e [Siemens](http://www.sci.siemens.com/) per lo sviluppo di smartcard basate su tecnologia Java. Per saperne di più date un’occhiata alla pagina dedicata all’evento da [SUN](http://www.sun.com/smi/Press/sunflash/9707/sunflash.970722.1111.html).
<< fig02.gif - Figura 2 >>
<< fig03.gif - Figura 3 >>
<< fig04.gif - Figura 4 >>
- [PersonalJava](http://java.sun.com/products/personaljava/): per i device con capacità di networking destinati al mercati consumer, personal computing e mobile computing, WEB connected television o telefonia intelligiente. Progettato per essere ospitato da sistemi operativi Real Time. Un interessante novità, appena rilasciata da JavaSoft per i device basati su PersonaJava, è il software [Personal WebAccess](http://java.sun.com/products/pwa/) la vostra televisione o il telefonino della nonna diventano porte su Internet (anche la mia lavatrice!!??).
- [EmbeddedJava](http://java.sun.com/products/embeddedjava/): per dirla alla Ferrini: "*lo dice il senso stesso della parola*". Principali destinatari sono i costruttori di strumentazione industriale, low-end phones e fax-machines, router e switcher di rete, elettrodomestici e così via.

Ecco una lista di PersonalJava/EmbeddedJava Resellers: Acorn, Chorus, Geoworks, Lucent Technologies, Microtec, Microware, QNX, WindRiver Systems.

Figura 5
Figura 5
Figura 6
Figura 6
Figura 7
Figura 7

Il 9 gennaio, Sun ha annunciato un accordo con il gigante delle telecomunicazioni via cavo Tele-Communications Inc. (TCI) per incorporare la piattaforma PersonalJava come uno "standard software application environment" nelle set-top boxes digitali.

Per il settore dei sistemi operativi la SUN rilascia la famiglia di prodotti JavaOS:

> - JavaOS: o meglio JavaOS for Network Computers

> JavaOS for Appliances: (in origine CHORUS/JAZZ) per i sistemi real time

Per quanto riguarda l’hardware invece, SUN ha rilasciato la specifica javaChip per i produttori terzi. Tra i primi produttori a dichiarare la propria intenzione di rilasciare sistemi basati su PicoJava niente meno che IBM, Fujitsu, LG Semiconductors, NEC e Rockwell-Collins.

La SUN Microelettrics produrrà in prima persona:

> - picoJava: implementazione su chip della JVM progettata per sistemi embedded nel segmento consumer come telefonini, televisori, punti informativi etc.

> microJava: un picoJava esteso per I/O, memoria, communicationi e funzioni di controllo. Destinazione: network computers, applicazioni di networking a basso costo, PDA, controllori programmabili, dispositivi di telecomunicazione, giochi non professionali

> ultraJava: un Java Processor ad alte prestazioni destinato ai networks computer, giochi e 3D grafica ed imaging.

  • Mitsubushi lavora da due anni per portare la JVM sui propri sistemi embedded basati sul processore RISC M32R/D. Applicazioni target:

> - Sistemi portatili o palmari con Low-power Consumption (PDA, PIC, Data Pager, Wireless Smart Phone )

> Controllori per applicazioni telematiche o grafiche High-performance con grande ampiezza di banda (Network Protocol Controller, Digital Still Camera, Navigation System with Graphic Display, TV/VCR Graphics User Interface, Video Games)

  • Un punto di vista alla rovescia ci viene dall’accordo tra SUN e Metaware per il porting del sistema di sviluppo High C/C++ <sup>TM</sup> Embedded Toolset su picoJava. In altre parole il software già sviluppato in C/C++ con i prodotti Metaware girerà sui javaChip.
  • Patriot produce un’interessantissimo sistema basato sul proprio RISC PSC1000. La particolarità è che il processore della Patriot, utilizzabile in sistemi embedded ma con la potenza di un RISC 32 bit a 100 Mips, ha un’architettura basata su stack molto simile a quella della JVM e riesce ad ottimizzare l’esecuzione del Java code al livello di un JavaChip.
  • Sempre la Rockwell-Collins, produttore leader di PLC e dispositivi per il controllo industriale, produce il chip JEM1 che esegue direttamente il codice Java.
  • Sono in fase avanzata di realizzazione i primi compilatori in codice nativo, oltre a quelli in progetto alla stessa SUN. Si attende, quindi, che nell’immediato futuro Java possa essere usato su alcuni RTOS (Real time Operative System) come un qualsiasi linguaggio di programmazione, fermi restando i vantaggi già citati. La californiana Cygnus Solutions, in particolare, ha aggiunto jcl, un compilatore Java, come front-end del popolarissimo compilatore GNU. L’azienda ha inoltre annunciato un’intera suite di embedded systems tools per Java che dovrebbe essere disponibile nella prima metà del 1998. Il vantaggio principale dell’uso del codice GNU è che tutti i tools, i processori ed i controllori già coperti dall’attuale offerta di Cygnus sono resi disponibili immediatamente anche agli sviluppatori Java.
  • Nascono dialetti RT di Java con un alto grado di compatibilità sia con il linguaggio che con le JVM standard ed i comuni formati dei file class. Le specifiche di Java sono già pensate per il supporto di estensioni che non debbano stravolgere la compatibilità. Ad esempio il compilatore del linguaggio PERC (Portable Executive for Reliable Control), è in grado di inserire nei file di classe le valutazioni sulle risorse necessarie all’esecuzione dei diversi task ed aggiunge alcuni costrutti real-time alla sintassi standard di Java. Tuttavia la PVM (PERC Virtual Machine) può eseguire i comuni oggetti Java così come le JVM standard possono eseguire tutti i programmi PERC perdendo soltanto l’esecuzione in tempo reale. Sono sviluppate versioni mini per sistemi con poca RAM (PicoPERC): a costo di perdere parte della libreria standard e la garbage collection, rimane la compatibilità del byte code e tutti i vantaggi di semplicità e logica del linguaggio. K. Nielsen, creatore del PERC (che ama firmarsi prof. Kelvin Nielsen…) ha svolto anche un ottimo lavoro per la realizazione di un RT Generational Garbage Collector.
  • Vengono prodotte JVM atte ad essere eseguite sopra diversi sistemi operativi RT. E il caso di Mach J. Su questi vengono sviluppati prodotti più mirati come SoftPLC, un controllore programmabile totalmente Java, capace di far convivere oggetti Java e comuni programmi di PLC scritti con linguaggio a contatti (ladder).
  • L’americana Foxboro Company, che si autodefinisce "leader nei sistemi di automazione intelligente", e la francese Chorus Systems, di proprietà SUN e ben nota nel settore dei RTOS per sistemi embedded, hanno annunciato una partnership per sviluppare il primo real-time Object Request Broker (ORB) progettato specificatamente per l’automazione industriale e le applicazioni nel campo delle telecomunicazioni e camprendente Java tra i propri standard.
  • La Wind River Systems offre una versione per Java del proprio sistema di sviluppo, Tornado. Il Java Application Environment (JAE) è stato integrato nel RTOS VxWorks, dell’azienda americana.
  • Microtec, una divisione di Mentor Graphics, ha annunciato una suite of strumenti di sviluppo per Java, comprendente un Java compiler ed una estensione del suo X-Ray development environment per includere Java. La disponibilità commerciale dei tools è schedulata per la prima metà del 1998.
  • Motorola e SUN hanno stipulato un accordo che suona più o meno così: la SUN fornisce la licenza di produzione su tutte le proprie piattaforme e Motorola mette a disposizione il proprio know-how per portare l’esperienza maturata, in particolare nei dispositivi di telecomunicazione, su tali piattaforme.
  • La Psion Software plc, ben nota come produttrice di alcuni tra i più diffusi palm-top, ha annunciato l’adozione di un porting di PersonalJava basato sul proprio EPOC32 OS per device di tipo diverso dai desktop computer.
  • Ultimo ma non ultimo il colosso Texas Instruments ha stretto alleanza con SUN ed adotato Java, in particolare, per le seguetni tipologie di prodotto: Digital Cellular Phones, Pagers and Wireless Local Loop Terminals.

Come preannunciato, le notizie suelencate non approfondiscono alcun argomento in particolare ma vogliono dare l’esatta sensazione di quanto venga presa sul serio l’alternativa Java nel mondo dei sistemi embedded. La quantità ed il calibro delle aziende coinvolte è tale da poter far decidere il lettore eventualmente impegnato nel settore ad investire il proprio tempo nello studio del linguaggio: se poi dovesse rivelarsi una bufala, saremmo comunque in buona compagnia!

Nei prossimi numeri di Mokabyte vorrei entrare nei dettagli di qualche prodotto o tecnica particolarmente interessante per Java embedded, iniziando con il PERC che, probabilmente, risulta tra i vari prodotti software quello meno propenso ai compromessi e più adatto alle applicazioni strettamente real-time.

Piergiuseppe Spinelli svolge attività di analista/programmatore dal 1980. Si è occupato di training e di sviluppo di sistemi, particolarmente nel campo della supervisione di processo. Ha lavorato per aziende dei gruppi Saint Gobaing, Angelini, Procter&Gamble, Alcatel/Telettra, SIV e per vari enti pubblici e privati. E contattabile all'indirizzo <spinellip@sgol.it>.