O3S Inside

All about the Open System Simulation Solution

Visualize platforms topology

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:

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.

, , , ,
4 December 2012 at 15 h 41 min Comments (0)

O3S and NodeJS: the proof

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.

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);

27 November 2012 at 19 h 02 min Comments (0)

O3S and NodeJS: clouds, but not only

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.

,
24 November 2012 at 17 h 34 min Comments (0)

O3S on ARM

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…

, ,
21 May 2012 at 16 h 55 min Comments (0)

En attendant la version 2.0.0

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

11 October 2011 at 11 h 21 min Comments (0)

Accord de collaboration entre OpenTekhnia, TechniWare et Geensyde

OpenTekhnia, TechniWare et Geensyde ont conclu un accord pour proposer des solutions de simulation de systèmes embarqués et/ou distribués innovantes. Cet accord est motivé par le désir de chaque partenaire de pouvoir mettre en commun leur savoir-faire dans ce domaine, souhaitant proposer une valeur ajoutée « produits et services » à leur clientèle grands-comptes industriels.

La collaboration s’attachera à répondre aux besoins d’amélioration du processus d’ingénierie des systèmes embarqués, par une offre d’accompagnement focalisée sur l’efficience.

OpenTekhnia, une jeune entreprise innovante, membre du pôle Systematic et Intel Software Partner, et TechniWare société spécialisée dans les bancs de simulation pour le test, l’intégration et la validation des systèmes, ont développé la technologie innovante O3S (Open System Simulation Solution®).

Cette plate-forme complète de simulation, permettant la mise en oeuvre de bancs de test, d’intégration et de validation de systèmes embarqués avec un coût de possession très concurrentiel.

Ces solutions permettent notamment le test d’un système en usine en se situant aussi près que possible des conditions d’opération de l’utilisateur final. Ceci grâce à la capacité de simuler tout ou partie de l’environnement d’utilisation final, mais aussi une partie des équipements sous test eux-mêmes.

Dans le cadre du développement de nos solutions « model driven architecture », l’offre « d’ingénierie globale» de Geensyde et l’expérience de ses consultants viennent renforcer notre offre d’outils pour le développement des systèmes.

Témoignage

« Les technologies développées par Open Tekhnia et TechniWare associées à l’offre «d’ingénierie globale» de Geensyde, nous permettent permettent de répondre de manière plus efficiente aux besoins d’outillage qui nous sont exprimés par nos clients. »

Thierry BILLOIR
Président

, ,
8 June 2011 at 9 h 02 min Comments (0)

O3S v1.3.0 is out

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:

  • Add of Android python connector for using UIDesigner on Android Mobile devices (tested with Honeycomb on Acer Iconia A500)
  • Simulation time management (see test example)
  • SCXML: bugs corrections, add of the message decoding functionality coupled to SCXML models/simulaitons
  • Add of an workspace (o3ssim) allowing the compilation of linux simulations/models (o3sdev VM)
  • Add of Android python connector for using UIDesigner on Android Mobile devices (tested with Honeycomb on Acer Iconia A500) » « Simulation time management (see test example) » Bug correction for states management (‘resolved’ becomes ‘initialized’): corrects a synchronization bug during the init phase SCXML: bugs corrections, add of the message decoding functionality coupled to SCXML models/simulaitons Add of an workspace (o3ssim) allowing the compilation of linux simulations/models (o3sdev VM) Small bugs corrections in HMIs (better management of the Bonjour services in o3sPlatformManager, for example)
v1.1.0:
  • Attach function for messages (data structures), variables, variables to endpoints
  • Ethernet encode/decode from xddl
  • Messages manipulation (equivalent to C struct, but also to data structures exchanged through messaging)
  • CAN bus on Janz emPC
  • Addi-Data drivers for AIO and DIO
  • Janz emPC with specific debian/Xenomai distribution (based on debian lenny)
  • Full python process for generating embedded python scripts
  • Dev environment with installed HMI and python connectors on Linux Ubuntu 10.04 for development beginners (avoiding the install of several dev tools) (o3sdev VM)
8 June 2011 at 9 h 00 min Comments (0)

O3S v1.0.7 is out

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

CORE-001 Distribution of parameters Data distribution between nodes v1.0.0
CORE-002 Bundle services Administration of O3S bundles v1.0.0
CORE-003 Script services Administration of node embedded scripts v1.0.0
CORE-004 Simulation services Administration of node embedded simulations v1.0.0
CORE-005 oCDL management Parameters management through oCDL v1.0.0
CORE-006 xDDL management Parameters management through xDDL v1.0.0
CORE-007 Parameters managent Management of parameters services and linking to real IO v1.0.0
CORE-008 Python remote administration Services allowing Python remote control v1.0.0
CORE-009 Python remote modeling Services allowing Python remote model execution v1.0.0
CORE-010 Generic AIO Generic analog IO management v1.0.0
CORE-011 Generic DIO Generic digital IO management v1.0.0
CORE-012 Generic Ethernet Generic Ethernet management v1.0.0
CORE-013 Generic serial Generic serial management v1.4.0
CORE-014 Generic CAN Generic CAN bus management v1.3.0
CORE-015 LabJack U12 driver Labjack U12 IO board availability v1.0.0
CORE-016 Addi-Data PCI drivers Addi-Data PCI boards availability v1.1.0
CORE-017 Janz CAN driver Janz CAN board availability v1.2.0
CORE-018 Janz serial driver Janz serial board availability v1.4.0
CORE-019 Dynamic model instaciation Instanciating scripts and simulations dynamically v1.0.0
CORE-020 Dynamic parameters attach Attaching (joiting) dynamically parameters and endpoints v1.0.7
CORE-021 Dynamic configuration persistency Save a given dynamically created configuration to XML format v1.0.7
CORE-022 Python persistency (cfg or admin) Save a python history for recreating a given situation v1.0.0
CORE-023 Logging services Services for logging in bundles or in simulations v1.0.0
CORE-024 SCXML Running SCXML v1.0.7
CORE-025 External models import External models import in C/C++ capability v1.0.0
CORE-026 Ethernet xDDL based communication Capability to manage dynamically the Eth messages decoding v1.1.0
CORE-027 CAN xDDL based communication Capability to manage dynamically the CAN messages decoding V2.0.0
CORE-028 Serial xDDL based communication Capability to manage dynamically the ser messages decoding V2.0.0
CORE-029 Ethernet fault infection Capability to dynamically inject errors V2.2.0
CORE-030 Simulation time management gettime provides a simulation controlled value instead of OS one v1.2.0
UI-001 Remote administration Remote administration (CORE-002 to 007) through dedicated ui v1.0.0
UI-002 Specific UI parameters access Remote access to paremeters through graphic objects v1.0.0
UI-003 Remote logging UI Remote logging from a dedicated UI v1.0.0
UI-004 Scope UI Scope like UI for signals visualisation v1.0.0
UI-005 Intranet/internet http remote for UIs Intranet/Internet remote use of the UI v1.0.0
UI-006 Visual dynamic configuration Dynamic « Simulink like » tool for sims and attachements v1.1.0
DEV-01 Model development Eclipse plug-in for model dev (import, dev) v1.2.0
DEV-02 Python dev Eclipse plug-in for embedded python dev v1.0.7


If you want a live demo, please contact us. For the moment we propose a live demo via Skype or we come to your office for it.

9 March 2011 at 9 h 35 min Comments (0)

La transformation de modèles: une technique d’avenir déjà à l’oeuvre

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)

Start: File -> New -> Other … EMF Generator Model
EMF Project: name your project (prefer .emf at the end of the name in order to avoid miseunderstandings)
Select a Model Importer: XSD Schema
XML Schema Import: load your XSD file and set the name of hte model (must end with .genmodel)
The project is created and you have there two files:
- genmodel one
- ecore model (a translation of the XSD Schema to ecore).
Now you need to generate adjacent projects needed for your modeling tool.
Open the genmodel file if not already done, and right click on the root of the tree displayed by the file.
Select « Generate All »
3 other projects have been created in the workspace:
<…>.edit
<…>.editor
<…>.tests
Graphical part: File -> New -> Project -> Graphical Modeling Framework: new GMF Project
Go to next screen and select « Show dashboard view for the created project »
During the following steps you’d better keep the emf initial project selected, so that the operations applies to it.
First, select tour « Domain model » and « Domain gen model » in your dashboard. The first one is your ecore gnerated file, while the second one is the genmodel file (both from your initial emf project, in the model directory).
Now we should be able to generate the graphics and tools using the guided derivation provided by the dashboard.
In future articles, we will enter all the details of creating manually (and more precisely) these graphics and tools.
Click on Derive in the dashboard for generating first the Graphic Def Model.
Name you file (most of the time we will be happy with the defaul one that follows your projects naming rules based on EMF model).
Then, in the next screen, select the root diagram element.
In the Graphical Definition screen coming next, select which of your elements are connectors and which are objects. You can also define the labels related to each object or connector.
You need to do the same for the tools.
Click on Derive in the dashboard for generating the Tooling Def Model. Do same kind of stuff as for the Graphic Def Model.
Now you need to map all this together. In order to do this, the simplest way is to use the « combine » action from the dashboard. At this level you need to chose wich are your input models and, for each element, which are nodes and which are links (a default proposal is given by the tool).
Once the mapping done, you have a new file in your EMF project: the gmfmap one.
At this stage, the last step is generating rour specific model editor prototype. First transform your current models in a new output model using the « transform » link in the dashboard. Checking the RCP value will let you generate a standalone editor prototype.
Once this done, generate your diagram editor.
The dashboard will let you know that you have reached 100%.
, , ,
15 December 2010 at 18 h 02 min Comments (0)

o3sDynamicUI: créer des synoptiques spécifiques pour O3S

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.

, , ,
13 October 2010 at 8 h 36 min Comments (0)

« Older Posts