SMART CITIES

As rail systems generate more data, developers need to rethink where and how they process information. Legacy systems moved data to the control center for analysis, but modern systems often keep this functionality on the train.

The challenge with this fog computing approach is that it creates a heavy burden for on-board computers. In addition to increasing the compute load, the need to retain data locally can create storage problems.

A smart database can help with both problems. When configured properly, a database can reduce processing and storage demands.

Rolling into the Fog

Fog computing has many benefits for rail systems. Such a configuration allows on-board computers to perform calculations in real time and act immediately. After processing at the train level, data migrates to a control center so that trend analysis can be conducted for the entire system.

Predictive maintenance is a good example of the types of benefits afforded to rail systems: On-board analytics can monitor acoustic data for bearing problems, temperature sensors for brake issues, and even track RFID and photo data to tie potential issues to particular cars.

Control and safety subsystems can also get in on the act; examples here include fire suppression, digital video surveillance, and air conditioning.

Databases Ride the Rails

Database management systems (DBMS) are essential to all these features—and choosing the right DBMS is a critical design decision.

An SQL database is one obvious option, but the highly organized and self-referential structure of SQL takes up a relatively large amount of storage space and processing power.

Most important, SQL is overkill. "Edge devices often do not need the sophistication of an SQL database," says Steve Graves, Co-Founder and CEO of McObject. End users won't see the database, so many features of SQL simply aren't relevant. Similarly, scaling is generally not a huge factor. While a train set may take on new subsystems over time, there are rarely dramatic shifts in requirements.

Edge devices do not need the sophistication of an SQL database.
— Steve Graves (@McGuy), Co-Founder and CEO of @McObject

Another option is to use loosely formatted databases, such as those using NoSQL. But data validation isn't inherent in these databases, so validation is left to the devices collecting data. If things aren't set up correctly, though, data could be entered incorrectly—rendering it useless at best.

According to Graves, a better option is to use a database designed specifically for embedded. In Graves' view, "the ideal setup shares some attributes of NoSQL databases that are applicable," but at the same time "offers native, non-SQL low level (and type safe) programming interfaces. These are usually faster than SQL, easier to program, and carry a smaller footprint."

Graves points to McObject's eXtremeDB in-memory database system as an example. By using a hybrid architecture that pulls from both the SQL and NoSQL worlds, eXtremeDB offers a robust yet lightweight database.

Graves adds that this data structure minimizes deployment cost because it minimizes resource consumption. A lightweight database allows customers to use less costly processors and require less system memory on edge devices.

Security is a Priority

For better or worse, security needs to be stitched into just about every embedded system these days. Rail systems are no exception.

Graves notes that because eXtremeDB was developed specifically for embedded systems, data integrity was a paramount concern from the start. So it's no surprise that eXtremeDB supports secure communication through SSL and can fully encrypt database contents.

The DBMS also offers a type-safe programming interface. The interface eliminates the most common source of database corruption, namely, the use of void pointers to pass data between the database run-time and the application.

Similarly, eXtremeDB is designed for maximum reliability. For example, the database comes in a fault-tolerant version known as eXtremeDB High Availability Edition. This runtime maintains multiple identical databases that enable hot failover. Typical configurations include:

• Multiple processes or threads on a single piece of hardware
• Two or more boards within a chassis
• Multiple computers on a LAN

Rail-Ready Hardware

Whatever hardware you choose, any rail system needs to be ruggedized. Trains constantly rattle, accelerate and decelerate, and go through all kinds of weather. And of course, you'll need enough computing horsepower to work with your data.

One solution that fits the bill is Nexcom's NROK 1020 Train Computer (Figure 1). Designed with a quad-core Intel^® Atom^™ x5-E3930 processor, this machine has the performance, I/O, and rugged reliability needed for rail applications. In addition, the latest-generation Intel Atom processors feature numerous new security features and hardware-enhanced encryption to keep your system safe.

Meet Your Own Design Objectives

While databases might not be the first thing you think about when building a rail system, they shouldn't be overlooked. A smart database designed specifically for embedded can help you meet multiple design objectives. These include high performance with low hardware and storage cost, minimal communications traffic, and high reliability. Given these potential advantages, an embedded database is worth a look.