Truly profound technologies become part of everyday life. Motors,plastics, computers, and now networking have made this transition inthe last 100 years. These technologies are embedded in billions ofdevices; they have melted into the assumed background of the modernworld.
Another stage is emerging in this progression: pervasive, real-timedata. This pervasive real-time infrastructure is an extension of theInternet; the new capability is to connect devices at very high speeds,rather than people at human-interaction speeds. Just as the 'web'connected people and fundamentally changed how we all interact,pervasive data will connect devices and change how they interact.
Today's network technology makes it easy to connect nodes, but notso easy to find and access the information resident in networks ofconnected nodes. This is changing; we will soon gain the ability topool information from many distributed sources, and access it at ratesmeaningful to physical processes. Many label this new capability the'network centric' architecture.
However a more appropriate term is “data centric” because thechange, fundamentally, is driven by fast, easy availability ofinformation, not by the connectivity of the network itself. Whateverthe name, this infrastructure will drive the development of vast,distributed, information-critical applications (See Figure 1, below ).
|Figure1. Technology is evolving from data networks to pervasive anddistributed data. With pervasive data, all information is availableanytime at any place, without consideration of its origin.|
Technology is evolving from data networks to pervasive data. Withpervasive data, all information is available anytime at any place,without consideration of its origin Real-time middleware is thetechnological key driving this transformation. We will now examine theissues in developing a middleware that can succeed.
The rise of data-centric thought
Most systems built today are connected to a network. However, most arenot designed to flexibly deliver data to support truly distributedapplications. They are instead designed around clients and servers,application interfaces, and other code-centric concepts. The realchange is from codecentric or architecture-centric thinking todata-centric design. Instead of configuring clients and servers, orbuilding data-access objects and invoking remote methods, datacentricdesign implies that the developer directly controls informationexchange.
Data-centric developers don't write or specify code. They build a'data dictionary' that defines who needs what data. Then they answerthe information questions: How fast is the data coming? Does it need tobe reliable? Do I need to store it? Where is it coming from? Whathappens if a node fails?
With this information in hand, the next task is to map theinformation flow. Publish- subscribe middleware isthe key enablingtechnology for data-centric design. Publish-subscribe nodes simply'subscribe' to data they need and 'publish' information they produce.
Thus, the information flow map is directly translatable topublishers and subscribers. The middleware does the rest: messages passdirectly between the communicating nodes. The fundamentalcommunications model implies both discovery ” what data should be sentwhere ” and delivery ” when and how to send it .
This design should be familiar; it mirrors time-criticalinformation-delivery systems in everyday life. All mass-mediacommunications, including television, radio, magazines, and newspapers,are fundamentally publish-subscribe technologies. Publish-subscribesystems are good at distributing large quantities of time-criticalinformation quickly, even in the presence of unreliable deliverymechanisms.
With direct access to data, system integration isorders-of-magnitude easier. Designers have always built interfacespecifications that detail which information flows between systemcomponents. With a publish- subscribe information bus, the interface isthe design; interface specifications can essentially be directlyimplemented (see Figure 2, below). This data-centric design techniqueeliminates numerous intermediate steps, and with them all the overheadand opportunity for error they entrain.
|Figure2. Conventional vs. data centric system design: the interface is thedesign|
Networking middleware is a code layer above the basic TCP/IP stack thatimplements sophisticated data transfer and management models.Networking middleware consists of software agents that shuttleinformation between different components of complex, distributedapplications.
There are many types of middleware. Distributed hash tables andpeer-to-peer document sharing, including technologies like BitTorrentand Kazaa, create a distributed source for individual files. They werefirst widely used (or abused) by music sharing services. Thesetechnologies are massively scalable sources of relatively low-bandwidthdata. They make virtually no attempt to keep the data consistentthroughout the network.
Transactional systems, designed for applications like banking, offerguaranteed integrity and persistent data, even in the face of systemfailures. However, high-performance scalability is a challenge. Datadistribution and messaging systems strive to update multiple nodes withrapidly changing data at speeds measured in microseconds. Technologiesinclude the traditional 'middleware' such as CORBA, message queues likeIBM's MQueue, and publish-subscribe systems like JMS.
While some of these older middleware solutions deliver reasonabledata transfer performance, most target smaller systems of only a fewhundred nodes and leave issues of data consistency as an exercise forthe application.
The emergence of real time DDS
Embedded systems connect devices; since devices are faster than people,these networks require performance well beyond the capabilities oftraditional middleware. Hundreds of embedded designs have now beencompleted with advanced publish-subscribe middleware.
This experience drove the first accepted standard that targetsrealtime distributed systems, the Object Management Group's DataDistribution for Real Time Systems Standard ('DDS').
DDS is sophisticated technology; It goes well beyond simplepublishing and subscribing functions. It allows very high performance(tens of thousands of messages/ sec) and fine control over many qualityof service parameters so designers can carefully modulate informationflow on the network. A detailed description of DDS is beyond the scopeof this paper. However, it is based on very familiarconcepts. We present a high-level analogy here.
DDS is like a neighborhood news service for computers. It putsreporters at every 'house' and delivers the stories they write to everyother house that cares to subscribe. Each house has fine control overwhat news it gets when.
You can subscribe to every single update on every topic or weeklysummaries of just one. You can have reliable delivery directly to youriPod, or have them just toss a paper on your doorstep when they can.You don't know or care where the stories come from, so multiplereporters can back each other up to make sure you always get yourmorning traffic report.
You can even set deadlines for delivery, ask to be notified whenyour neighbors are on vacation, and much more. Of course, this is justan analogy; DDS does not target neighborhood or interhumancommunications. DDS targets high-performance networks. It can delivertens of thousands of 'stories' a second to any or every 'house' on yournetwork.
The 'stories' are data updates of any type; 'houses' are anycomputer or embedded device. The 'fine control' options are quality ofservice (QoS) parameters that finetune delivery requirements. QoSenables a dynamic contractual negotiation between every data publisherand subscriber to determine and set up access to a particular datasetunder a specified delivery terms.
This infrastructure fundamentally changes how easy it is to designand set up a highly-connected real-time networked application. Complex,distributed, information- critical applications are the next generationof computing. The impact on many of today's real-world applicationswill come much sooner and be just as transformational.
Let's examine the challenge of working in real-time, especially fordistributed systems. There is a famous Stanford PhD qualifying- examquestion that asks, “Why are clear things clear?” It's a trickquestion, because there is no property of materials that yieldsclearness. Things are clear because they don't absorb, reflect, orscatter light. Fundamentally, they are clear because they fail to beunclear.
Systems are real time for a similar reason: they fail to be non-realtime. Consider a control system that must respond to a sensor (e.g. atemperature rise) by changing some actuator (e.g., closing a valve). Torespond to the stimulus, the sensor must detect the stimulus, thatdetection must be reported to peripheral hardware, the peripheral mustinterrupt the CPU, the operating system must process the interrupt, theapplication must calculate a response, the response must be passed tothe actuator, and the valve must close.
If each of these steps takes a fixed amount of time, the system willbe deterministic. If those times sum to a small enough value, the valvemay close before the boiler overheats, and the system can be calledreal time. If any of these steps takes an unknown or excessive time,the system will fail to be real time.
If the sensor and actuator are connected over a network, the chain ofevents minimally includes creating a network message, passing thatmessage through the network stack, putting the message through sometransmission medium, receiving the message at the other node, passingit back up through the stack, and interrupting another processor thatcontrols the valve. Even this simple one-to-one system has many moreopportunities to fail to be real time.
Complex, distributed real-time systems present the interesting newchallenge. Throwing a network into the mix complicates things greatly.Network hardware, software, transport properties, congestion, andconfiguration affect response time.
'On time' may have different meanings for different nodes. Even thesimplest question of all, “what time is it?” can be hard to answer in adistributed real-time system.
But although it may be tough, solving the real-time challenge acrossa network is critical. It is the key to truly pervasive data. So, whatmakes middleware real time? The easy answer would be that middleware isreal time if it can always process requests in a sufficiently-shortdeterministic timeframe. Unfortunately, this is rarely possible or evendefinable in distributed systems.
Most designers cannot assume a reliable or strictlytime-deterministic underlying network transport, as most cost effectivereal-time systems must operate without these luxuries. Most systemarchitects do not know the real performance bounds of their distributedsystems. Usually, you know only that the network transport affords araw bandwidth capability that if properly managed should meet yourperformance and latency needs.. The key to successful distributedreal-time middleware is to optimize those two words: “properlymanaged”. That discussion requires a detailed exploration of the QoSfunctions of DDS which is beyond the scope of this article.
Data-centric development in action
Data-centric development methodology is not some speculative futuretechnology ” it is already in use today in a wide variety ofapplications. It is typically employed where the increased complexityof the application and the magnitude of the system design task makes amove to a simpler and more flexible development environment anirresistible proposition. Such systems also benefit from the enhancedperformance and scalability inherent in this data-centric designapproach. Let us look at two recent ” and very different ” examples.
Tokyo's Highway Line system consists of a centralinformation-control center and hundreds of information kiosks andterminals scattered along the city's highway system. They needed a lowmaintenance, high reliability communications system that wassufficiently robust for delivery of constant updates to the kiosks. Thedrivers and passengers who are stopped at the parking area rest stopsare able to get information on traffic conditions, projected arrivaltimes to particular locations, alternate routes, and enforcement pointswhere traffic is being redirected or controlled due to obstructions inthe roadways caused by construction or accident.
The size and complexity of such a widely distributed real-timesystem pose a number of specific design challenges, notably:
1. How to provide reliablereal-time information to commuters about arrival times, trafficproblems, changes in schedules, potential problems and alternate routes;
2. Ensuring the provision ofinformation to transit officials and employees on a timely basis;
3. How to ensure delivery ofthis information on transmission links that vary in bandwidth, signalto noise ratio, and physical location;
4. How to develop, operate,maintain and eventually upgrade a complex system running on a varietyof computer server and client platforms with diverse hardware andsoftware incompatibilities.
By using a publish-subscribe model based on DDS, the developers ofthe Highway Line network designed a system using asynchronous messagepassing between concurrently operating subsystems, connecting a varietyof anonymous information producers (central office) with many otherequally anonymous information consumers (kiosk and terminals).
In such a system, when a data producer ” the server – publishes somedata on a topic, all the consumers ” the kiosks and terminals -subscribing to that topic receive it. The data producers and consumersremain anonymous, resulting in a loose coupling of sub-systems and arobust service that decouples participants from one another, provideslocation transparency, and the flexibility to dynamically add or removeelements.
In addition to the benefits of performance and flexibility inherentin the datacentric publish-subscribe model, what also appealed to theTokyo developers was the speed and efficiency of the developmentprocess. Unlike the typical client/server link, DDS essentiallyprovides a connectionless API.
Thus it does not require that the system designer get involved inthe underlying communications protocols. The developer need only needto tell the system what the bandwidth constraints are, the informationneeded at each node, what actions needed to be taken, when to send itor to receive it, and what is required in response.
Instead of a direct, active link to a server in which the client isrequired to query for updates, DDS is very information centric, anddoes not require such active linkages, which require constant updating.
This allowed the Tokyo system developers to simply tell the DDS APIwhat information is needed at which terminal and on what schedule. As asubscription protocol, the system designers can designate beforehandthe quality of service and the delivery profile rather than negotiatingthis each time a transaction is initiated.
The flexibility of the publish-subscribe framework and the fact thatit is independent of the underlying server, terminal or networkhardware or software configuration also gives the developers of theHighway Line network the ability to be more open ended in relation tofuture extensions of the system in terms of number of terminals, theunderlying hardware or OS, the physical network and the bandwidthrequired.
Another, and perhaps even more challenging, application involves theuse of DDS in the US Navy's ambitious program to develop its Sea Power21 concepts in support of Joint Vision 2020 for airborne early warningsurveillance, battle management and Theater Air and Missile Defense(TAMD).
As part of this system, the US Navy's E- 2C Hawkeye aircraftprovides all-weather airborne early warning, airborne battle managementand command and control functions for the Carrier Strike Group andJoint Force Commander.
The newest variant of the E-2C (Hawkeye 2000) with its new missioncomputer, improved radar displays and Cooperative Engagement Capability(CEC), combines with the shipboard Aegis weapon system to provide anenhanced area defense system and will form the cornerstone of futureseabased TBMD.
DDS has been used in the development of the upgraded Hawkeyeproject, and has been selected for use in the next generation of theAegis system, due for deployment in 2008. Figure 3 below shows areal-world example taken from the design of the Hawkeye aircraft.
|Figure3. Functionally oriented software modules must talk to many othermodules. Grouping into functional clusers does nothing to change thatreality and ease software integration.|
Again, data-centric thinking transformed the whole architecturalapproach in this demanding 'hard real-time' application.Functionally-oriented software modules must talk to many other modules.Grouping into functional clusters does nothing to change that realityand ease software integration.
There is a new generation of connected systems in sight.Data-centric architectures will change the world by making informationtruly pervasive. Pervasive information, available in real-time, willenable much more capable distributed, data-critical applications.Real-time middleware is the technological key driving the data-centrictransformation.
The next exciting step is merging information distribution, storage,and discovery into a pervasive data model. These technologies areevolving rapidly. They already satisfy many of the realtime performancerequirements of embedded systems and are developing to integratehigh-performance data access to the enterprise.
Although there are many challenges in performance, scalability anddata integrity, a data-centric, pervasive-information future is coming.Soon.
Stan Schneider is CEO at Real-time innovations Inc .
Other Real Time DDS resources onEmbedded.com.
1) Building a effective real-timedistributed publish-subscribe framework: part 3
2) Buildingan effective real time publish-subscribe framework for a distributedembedded design: Part 2
3) Buildinga effective real-time distributed publish-subscribe framework: Part 1
4) OMG'sData Distribution Service Standard
5) OMGData-Distribution Service brings real-time to the Data-centricPublish-Subscribe model
6) Anopen standards approach to real-time COTS-based simulator design
7) Buildingmiddleware for security and safety critical systems
8) Publish-SubscribeProtocol Enables Real-time Embedded iAppliances
To read a PDF version of this story, go to “TheData-centric Future.”