Mobile ignition server for datalogging


This quostion could be posted many forums but decided to post it here to get most feedback.
We are planning to run ignition on mobile server which will be powered by battery and will got lots of power losses.
Application is mostly for datalogging but there is also couple clients online once and while.
Now we should decide which hardware ,os and database platform works best on this.
I am afraid that power losses will make os or database corrupt so if anybody has done something similar or have knowledge about these kind of solution we would be happy to hear more.
Now we are planning to use passive industrial pc with ssd and linux os.
For database is open but firebird could be suitable.
Also using “live distro” could be solution to make os load stable.

Tommi Vahtera
THT Control Oy


This is actually a topic I’ve been thinking quite a bit about lately. We’ve had the idea for more “embedded” Ignition data collectors for a while, but it recently came up again after talking to various companies at Oracle OpenWorld who are looking to introduce new ARM based machines that run Java. This is would advantageous for the embedded space because the power requirements are less than that of x86 based systems.

In particular, I have one of these units sitting on my desk right now, running Ignition. These are just dev units, and the ultimate field-ready device would look different (and would be spec’d differently - that product page currently shows a max temp rating of 40c, which is obviously not enough).

At any rate, the specific device isn’t so important, what is important is what a Ignition on a box would look like compared to regular Ignition. Several things we’re looking at:

  1. The data cache must be able to hold a lot of data - and the store and forward system needs to be able to run on a schedule.
  2. The system (internal database and data cache database) must be very fault tolerant, to deal with power interruptions, as you mentioned.
  3. Serial driver support will become more important.

One of the main steps towards accomplishing the first 2 is to make the database system used pluggable. Right now the internal database is based on HSQLDB, which has functioned well enough, but frankly we think it would be better to look at other options for these devices. SQLite in particular is a strong contender, but Oracle’s Berkeley DB offers some interesting features, if you don’t mind licensing it. Of course, if the system were more pluggable, it would be possible to experiment with any system, such as Firebird, or MySQL embedded. Another element that might come into play is how the cached data is represented. Currently it is serialized into a blob in a db. However, we might find that a straight file system approach is more appropriate. At least, there isn’t much of a reason why it shouldn’t be an option.

How many tags do you expect each of these units to monitor? What types of devices will you be connecting to?



Nice to hear that this is something that is interesting you also.
We have done quite long time datalogging solutions on industry and military areas .
Now customer requirements has grow so much that simpple datalogging is not anymore enough.
We tried to make more user friendly gui with using hmi panels but features and functions on hmis are not enough, so we decide to move using Ignition on datalogging and remote control platform.
Our case connected decices will be modbus tcpip based or/ and event based devices.
So mobile server will be like local data server and devices will be distributed on site or line. Communication will be done by lan or wlan. We can also use backfilling technic by our device so it can store data inside device and send it to mobile server by ftp when server come online.
Size or power requirements are not problem for us but enviromental is critical. Normally our datalogging solutions is specs for -40 to +85 and also atex proof.

We have tags in these applications maybe 30 to 100 so not so much.

Br Tommi

For database you will want one that is ACID compliant. My experience with BerkleyDB is that it does not suffer power failures very well. Something like Postgresql or MySql’s innodb should survive power failure with no problem. Given your point count, I’m guessing that there will not be a whole lot of data to store so performance will be less of an issue.

I have Postgresql running on my PC which gets rebooted too often (thanks M$) and I’ve never stopped it before rebooting. (sometimes with the power switch :smiling_imp: )


Datalogging performance will not be problem, in these cases “server” will run maybe 1-2 months and then it move different place. But when it runs it can get power lossess and Ignition and database should restart automatically after reboot.
We will make some testing with different databases, I will inform here what is results.



Yeah, I didn’t say it specifically in my post, but probably should have: we haven’t been very impressed with HSQLDB’s fault tolerance. That’s why we would like to look at adding support for other internal db systems, namely sqlite, which has a pretty good track record (and a huge install base- every iphone, for example).

One other idea is to look at remote db synchronization options. In this case, the box would be logging to it’s local db, and then periodically, your central server would connect to it an synchronize the data. I brought up BerkeleyDB before because I know they tout this type of feature, though I imagine you can find third party products for other DBs. The advantage to this is that data is open, and not opaque as in the data cache, so you could have a local terminal that has data available (perhaps only the last week or so) even when the main connection is down.