O3S Inside

Few days ago, we spoke about the new edges of O3S platforms thanks to Node.js-O3S integration.
One of the most interesting aspects is the very fast development of any new front-end, based on Javascript/HTML5 frameworks.
For those who know d3js framework, for example, managing data became wonderful. A visit on their web site would bring the arguments, if necessary.

But what about simulation data, testing data, test stand data etc. ?

A first example was given by our new o3sUIDesigner (tested with Chrome), but we started working on different other experiments based on the new O3S web friendly aspects. One of them, is the control of an O3S platform. Administrate it, but also schedule scripts and simulations, or load data, was a matter of programmatic Python actions or dedicated HMI actions (o3sPlatformManager app).  We have already insisted several times on the fact that Pyrhon is just one of the possible choices. Thanks to our SOAP based web services, any language that can implement SOAP clients is available, quite easily.

And now, take a look how simple it is with Node.js using the node-soap extension:

Code block

mdns = require('mdns')
_u = require('underscore')
...
soap = require('soap');
...
browser = mdns.createBrowser(mdns.tcp('o3s'));
browser.on('serviceUp', function(service) {
	var node = service.txtRecord;
	node.admin = {};
	var baseurl = 'http://' + node.ip + ':' + node.soapPort + '/soap';
...
                       soap.createClient(baseurl + '/BundleAdmin/BundleAdmin', function(err, client) {
				node.admin.bundle = client;
		  		node.admin.bundle.getBundleList(null, function(err, result) {
			 		node.bundles = result.return;
			 		if (! node.bundles) node.bundles = [];
			 		_u.each(node.bundles, function(n) { n.type = 'bundle'; });
		  		});
...
}

Well, easier is difficult. But what does it mean ? Just that a good Javascript developer would be able to develop an O3S administration front-end in, oh, let’s say 5 days. (Mobile) Web apps are now ready to impress you…

So, here is our new o3sPlatformOrganizer. It is a “new age” o3sPlatformManager alternative (work in progress). See below how it looks like for the moment:

You could like, or you could hate, but the hidden story there is that you could do it in the way that you want, taking care about what an user should see. Future is managing big data. Platform administration data is already big data for human operators. And this is definitely true for test parameters or test results data.

Just take care about what is newly possible to do with this technology. And let your imagination do its job, than code it. In five days.

Few days ago we were talking about the merge of O3S and Node.js. Today a simple example: in less than 100 lines of code, we have an O3S data server than can manage bi-directional realtime updates to and from the o3sUIDesigner web app. Just easy.

o3sUIDesigner web app running on Chrome browser and updated by O3S/NodeJS web server.

Code block

var connect = require('connect');
var io = require('socket.io');
var nodeo3s = require('nodeo3s/nodeo3s.node');
var resolver = new nodeo3s.Resolver('o3shttp', false);
while (!resolver.getVariablesNames()) {}
console.log('[O3S resolved]: ' + resolver.getVariablesNames())
const O3SHTTP_PORT = 16061;
const O3SHTTP_IP = '192.168.0.12';
const APPDIR = '/Users/vandrito/Documents/web/o3s/o3sd3ui'
var server = connect.createServer(
    connect.static(APPDIR)
).listen(O3SHTTP_PORT, O3SHTTP_IP);
var wsserver = io.listen(server); // Wrap your connect server with Socket.IO
wsserver.configure(function() {
	wsserver.set('log level', 1);
});
wsserver.on('connection', function (ws) {
  var variablesToRefresh;
  var running;
  var remote;
  var interval;
  
  ws.on('message', function (msg) {
  	var msgdata = msg.split(':');
  	if (msgdata[0] === 'RUN') {
		variablesToRefresh = msgdata[1].split(',');
		running = true;
		interval = setInterval(function () {
			var	vlist = resolver.getVariablesNames();
			if (vlist && running) {
				if (variablesToRefresh.length > 0) {
					var msg = 'REFRESH:';
					for (var i = 0; i < variablesToRefresh.length; i++) {
						if (variablesToRefresh.indexOf(vlist[i]) >= 0) {
							var value = "+resolver.get(vlist[i]);
							var timestamp = resolver.timestamp(vlist[i]);
							msg += vlist[i] + ',' + timestamp + ',' + value + ';';
						}
					}
					msg = msg.substr(0, msg.length-1);
					if (msg.length > 0) {
						ws.send(msg);
					} 
				}
			}
		}, 100);
	} else if (msgdata[0] === 'ALIVE') {
		remote = msgdata[1];
	} else if (msgdata[0] === 'UPDATE') {
		row_variablesToUpdate = msgdata[1].split(';'); 
		var	vlist = resolver.getVariablesNames();
		if (vlist && running) {
			for (var i = 0; i < row_variablesToUpdate.length; i++) {
				var row_variable = row_variablesToUpdate[i].split(',');
				var vtype = resolver.type(row_variable[0]);
				if (vlist.indexOf(row_variable[0]) != -1) {
					if (vtype === 'bool') {
						resolver.set(row_variable[0], row_variable[1] === 'true' ? true: false);
					} else if (vtype ===  'byte') {
						resolver.set(row_variable[0], parseInt(row_variable[1]));
					} else if (vtype ===  'short') {
						resolver.set(row_variable[0], parseInt(row_variable[1]));
					} else if (vtype === 'int') {
						resolver.set(row_variable[0], parseInt(row_variable[1]));
					} else if (vtype === 'long') {
						resolver.set(row_variable[0], parseInt(row_variable[1]));
					} else if (vtype === 'double') {
						resolver.set(row_variable[0], parseFloat(row_variable[1]));
					} else if (vtype == "string") {
						resolver.set(row_variable[0], row_variable[1]);
					}
				}
			}
		}
	} else if (msgdata[0] === 'STOP') {
		running = false;
		clearInterval(interval);
		console.log('RUNNING = false ['+ remote +']');
	} else if (msgdata[0] === 'RQVARLIST') {
		var vlist = resolver.getVariablesNames();
		ws.send("VARLIST:" + vlist.join(','));
	}
	ws.on('disconnect', function () { 
		console.log('Disconnection [' + remote + ']');
	});
  });
});
console.log('Server running at http://' + O3SHTTP_IP + ':' + O3SHTTP_PORT);

When about Javascript, well… nobody is neutral. Some love, some hate, while some others do not. Yes, nobody can say that he just does not care ! At least, within the Web developers world. On the other hand, it’s a script language supposed to be fully related to the Web, according to masses.

What about Javascript in industry ? Most of the time we can find it in… web technologies based apps: intranet, light clients, user experience etc.

Starting with Google’s V8, Javascript entered, however, in a new era. Era of performances, efficiency and wide spreading. Javascript is more than a language: is the new lingua franca of the developers. And not only in the Web.

Take the example of the BeagleBone. A wonderful little embedded board for DYI that runs NodeJS. And here we are. More than just the V8 stuff, NodeJS has demonstrated how wonderful Javascript could be for I/O access. Just perfect.

So, embedded just for Web Servers ? Not at all. Independently of the BeagleBone idea, we have tried to demonstrate it with a very first step of work: integration of O3S with NodeJS.
What does it mean ? Means that you can do something like this:

> node myO3SJavascriptApp.js

and have an access to the O3S distributed architecture within a given platform.

Means that you can write in Javascript something like:

o3sResolver.set("myORSVariableName", newValue)

and have a real output somewhere on an O3S node (nothing to do with NodeJS node meaning) affected by this Javascript line.

Means also, of course, that you can create with just few lines a web server that “knows” all the O3S variables and spread them out thanks to Socket.IO NodeJS module, realtime, for any browser Javascript clients.

Means just that if you like Javascript, you can write apps for O3S with it.

Of course, we could talk about cloud computing. Fashionable subject. But it is not because the words are misused that we should not try to talk about.

The capability of integrating NodeJS with O3S is also good news for the simulation platforms clustering. Starting from now, we can imagine using all the advantages of cloud computing NodeJS related developments, in order to integrate this stuff within an O3S platform as a services cluster.

For simulation only purposes, this is quite obvious. Thanks to O3S node auto-detection mechanisms and multiple platforms single entry management, it is very easy to create a fully virtualized environnement controlled by web apps and dynamically reconfigurable (this is already partially available from now).

For hardware in the loop situation, this would be a little bit more tricky. Just because platform as a service means also remote control and computing and this could not be done if hardware configuration needs to change. However, when a project is mature enough, the whole stuff (simulation platform + hardware to be tested) could become a single platform to be shared between different teams. Then, NodeJS O3S port would make sense.

Several months that we are working on making available O3S for ARM platforms, first, through a very classical aspect: an iPad app. Few weeks ago, the first version of the O3S scope was made available for iPad (ok, don’t look on the app store for it, since this is not the distribution mode that we have for O3S, of course…). Today, a new step: O3S code library (data synchronizer) runs on a Genesi EFIKA MX Smarttop, on the top o a Maverick Ubuntu distribution for Arm processors. That’s a great step for several new uses:

- new smart IO units based on ARM processors (AddiData MSX-Box, for example)

- embedded applications for command and control ! Yes, O3S is not just simulation, but also a very attractive abstraction layer for command and control of remote devices like robots. We currently work for running a robot simulation environment with one real robot based on Genesi ARM PC and some Phidgets control boards.

So O3S keeps on exploring new uses…

Beaucoup de changements profonds dans la version 2.0.0 comme l’introduction d’un middle-ware maison pour la synchronisation des données. Mais en attendant cette version, voici 3 captures d’écran des GUIs O3S en version 2.0.0:

Le nouveau o3sPlatformManager

Le nouveau o3sUIDesigner avec des changements invisibles comme la possibilité de scripter en Javascript au niveau du synoptique ou encore la possibilité de relier les objects graphiques entre eux et plus seulement aux variables O3S.

La nouvelle interface graphique de o3sScope, mais pas seulement: la version 2.0.0 améliore les performances d'affichage et intègre le coeur de synchronisation des données à travers un plugin pour Air® 3.0 (la même solution est adoptée pour l'UIDesigner également)

La version 2.0.0 de O3S sera un grand cru. Sans apporter beaucoup de nouvelles fonctionnalités, elle consolide fortement la robustesse, améliore notablement les performances et permet à l’utilisateur une prise en main plus facile. Les GUIs sont de ce point de vue un apport évident, mais ce sont des outils comme O3SStudio permettant le développement d’applications pour O3S (Python, C/C++) qui donne véritablement de la puissance à la solution.

A bientôt pour la présentation de O3S 2.0.0

New version this month: the v1.3.0 brings several new features like the o3sConfigManager (a “Simulink like” configuration tool: in fact the possibility to drag and drop configuration and deployment elements like simulation models and variable attachements), or serial link XDDL encoding/decoding.

Just a reminder of previous versions’ features compared to v1.0.7:

v1.2.0:

A new version of O3S has been issued. The following functions are available (the functions currently available are tagged v1.0.7):

Lorsque j’ai commencé à travailler sur le sujet MDA et la transformation de modèles, j’ai eu un petit peu du mal, j’avoue. Tout paraissait simple. J’ai compilé ci-dessous une micro-tutoriel: mise-à-part la réalisation du modèle métier lui même, cela ne prend pas plus de 30 minutes pour réaliser un prototype d’éditeur Eclipse dédié spécifiquement à votre modèle. A l’aide de EMF (Eclipse Modeling Frameworks) et GMF (Graphic Modeling Frameworks) vous pouvez tout faire, paraît-il. La preuve: dans la compilation ci-dessous, j’importe un XSD me servant de modèle pour réaliser l’éditeur qui va bien, càd un éditeur dédié à mon modèle où les objets graphiques lui correspondent, ainsi que les outils de dessin/édition disponibles. J’ai appliqué ce tutoriel à un modèle de données de signalisation ferroviaire, en deux étapes: d’abord un modèle simplifié, puis un modèle plus complet et nécessairement bien plus complexe. Dans le premier cas les choses se sont passées effectivement en 15min, dans le deuxième, hmmm, ce fur plus dur. Voici donc ce tutoriel (inspiré comme je l’ai dit de diverses sources et que j’enrichirai au fur et à mesure sur ce site):

Requirements: Eclipse Helios installed with modelling tools packages (EMF, GMF)

La nouvelle version de o3sDynamicUI se veut d’une simplicité absolue: sur un tableau noir vide, votre espace de travail, vous pouvez rajouter une panoplie d’objets graphiques de contrôle (boutons radio, boutons radio discrets, boutons simples) ou de visualisations (jauges de toutes sortes, leds, graphiques XY ou YT) que vous reliez ensuite à des paramètres de la plate-forme de simulation O3S. Vous avez ainsi la possibilité de créer votre synoptique spécifiques, allant d’une replique d’une console de conducteur de train à un oscilloscope multi-écrans, en passant par une vue bas-niveau de visualisation et de contrôle des entrées-sorties physiques.<br>

<br>

Basée sur la librairie tekhniaG que nous avons réalisé sous license LGPL, cette application tire profit des capacités graphiques des technologies Adobe®, en particulier dans un environnement desktop s’exécutant sur Adobe® Air®. TekhniaG est disponible sur Google Code.