Chapter 2. Frequently Asked Questions

Hard and soft are nebulous terms that exist because it's hard to define the exact characteristics of systems called real-time, so attempts to, in turn, define them exactly often run into the same difficulties. Here are some thoughts.

Since hard real-time defines a requirement to be able to respond repeatedly within the time constraints, this implies a level of reliability, which requires better response to error conditions. While stopping with a "disk full" error may be reasonable for an accounting package it is unacceptable for a control of a nuclear power plant.

People commonly use "soft real-time" to refer to systems that need to be very responsive and reliable, when in fact there is no fixed critical deadline. Examples make the point clear.

Another way to think about it is to think of hard as meaning difficult, and soft as not as difficult. Some system resources are difficult to schedule in a priority-driven preemptive (PDPE) fashion, such as interrupts, and it is difficult to load an entire kernel in only a few 100k of memory. Hard real-time operating systems manage to do this. "Softer" real-time operating systems, on the other hand, may have a larger memory footprint and not allow as many system services to be controlled by the application engineer, but still schedule timers, semaphores, and tasks in a PDPE manner. And some systems may not even schedule semaphores or file system I/O in a PDPE manner, but still have an optional "real-time" scheduler.

Applications are also described as hard and soft real-time according to how demanding (difficult to achieve) their requirements are. Typical hard real-time applications are computation-intensive periodic tasks, such as sampling image boards at 1 kHz, logging the image, and performing complex mathematical operations on the image data, all within the specified time frame, indefinitely, with no missed deadlines. A system that needed to do the same things, but only at 100 times a second, without the requirement that the image board be sampled every .01 seconds +/- 2% as long as it was sampled 99 or 100 times a second, would be called softer real-time.

Many real-world embedded system and control/SCADA applications have a combination of hard, soft, and not real-time requirements.

Real-time systems of all "hardness" are generally distinguished in their design, and particularly in their documentation, by an attention to the detailed performance characteristics (such as speed and determinism) of all system services. Non-real-time systems tend not to consider these issues, assuming that if you need something done more predictably on time, you can get a faster machine, and optimizing system services for better average speed, at the price of occasional latency spikes.

Typically you configure a neural network (NN) application by feeding it with a lot of sample data that contains the inputs and corresponding outputs that you would normally expect in your process. Consider a pollution control system on an incinerator as an example.

The engineers spend quite a while gathering sample data using very expensive measurement devices. This data includes readings of the gases being produced by the plant under different operating conditions. The data is then fed to the NN application, and over time it develops a model that matches the behavior of the actual plant. The engineers test the model until they are happy that the model accurately predicts what type of gasses will be produced from the appropriate set of simulated plant conditions. Then the expensive measuring devices are removed and replaced with a NN application that reads the actual plant parameters and continuously predicts the gases being produced. The engineer then controls his plant so that he runs in a condition where the NN predicts that he will not be producing any harmful gases, but he doesn't have the expense of continuously measuring for these gases.

NN are specialized applications and not good for all types of application. They are also expensive to develop and maintain.

To make an OPC server for QNX, you need an OPC server in MS-Windows that can translate the various requests into TCP/IP messages which you then send to another server in QNX. The QNX server would offer either a COM-compatible interface for QNX tasks to use, or a proprietary interface. COM is a poor choice of interface unless you have Windows code that you are trying to port to QNX without modification. We have never heard of anybody even attempting a COM compatibility library for QNX. A proprietary interface based on S/R/R messaging (in QNX 4) or MsgSend/etc. (in QNX 6) would be simpler and more efficient.

We have taken essentially this approach with our Cascade DataHub product that offers an both OPC and DDE interfaces in Windows, and mirrors data over TCP to our Cascade DataHub in QNX

Broadly speaking, a protocol is an agreement between two parties that defines the rules by which they communicate so that there is no confusion. Take a telephone conversation for example - when the phone rings, you follow a protocol unconsciously:

If at any time, there is no response, then the person waiting for a response says "are you still there?", and possibly repeats the previous statement.

This same behavior occurs between computers, and between programs. They need to agree on the protocol, otherwise everybody talks at once and nobody can understand anything.

There are some protocols that are referred to as "hand-shaking". This is essentially the protocol by which two parties determine who is allowed to talk now. Again taking the telephone conversation, there are occasions when both people try to talk, and there needs to be a way for one of them to say "shut up and listen for a second". Handshaking is essentially a way for programs to say "shut up and listen" in such a way that there is no confusion. A good example of this is the RTS/CTS (Ready To Send/Clear To Send) lines in a serial connection, where a program that wants to send information must first raise the RTS line (make it a 1), then wait until the receiver raises the CTS line, indicating that it is ready to receive.

Sometimes the protocol by which two programs establish a connection and authenticate each other is referred to as handshaking, but this is not as common as the above usage.

DDE is not dead. It continues to live in a world where alternative interprocess communication standards abound, continuing to fulfill a role that is not well covered by other mechanisms. The competition with DDE is COM, with its variants for OLE, OPC and ActiveX. The reality is that DDE is simpler, and therefore faster, than the equivalent COM interface if implemented as a separate process. DDE is much easier to implement in code, and offers a particular data model as (name, value) pairs. In the case of process data, this model is well suited, and therefore offers the best cost/benefit ratio when programming for process data.

DDE is established in a much wider range of tools than OPC, which is targeted at the process control environment. The OPC standard is large and difficult to implement, and is not appropriate for applications such as Excel, and Word, or generally for any non-process oriented software. DDE on the other hand is implemented in most commercial programs, including process-oriented programs such as HMIs. This widespread availability makes DDE a good choice for wider data sharing.

Periodically new technologies come out based on DDE. Two specific examples are AdvanceDDE from Rockwell, and FastDDE from Wonderware. I think the fact that AdvanceDDE and FastDDE exist and are being actively developed suggests that people understand that DDE is not a dead technology.

The better question may be: Is DDE better than OPC? (OPC is a COM interface specification.) The answer is, it depends. If you are developing the client software, and you are comfortable with COM/OPC, then OPC is a more general solution. There is a wider range of facilities available in OPC, and if implemented as an in-process server (DLL), the speeds are unassailable. If you are not interested in doing a great deal of programming, or if you only have access to an OPC server as a separate process, then DDE may be a better choice. If you plan to send your data to an application that does not support OPC, then you will have to use DDE.

DDE and NetDDE are quite different technologies. DDE is the first crack at IPC offered by Microsoft when they decided that their OS was "multi-tasking". The intent was simple transmission of (name,value) pairs, and it was implemented in as simple a manner as they thought possible. It is well established and robust, once you figure out how to implement it correctly. NetDDE is an extension created by Wonderware, the makers of InTouch. It is an attempt to extend the DDE semantics to the network. It does indeed show real problems with more than a few nodes, and everybody who has tried to use it is aware of this.

We don't use NetDDE (the Wonderware mechanism). It is not reliable. We use local DDE (the Microsoft mechanism), which is reliable. The networking portion of our Cascade Connect connection is done using TCP/IP. We carefully handle timeouts, breaks, re-connections, multiple connections, multiple QNX hosts, etc. at the TCP level. Once the message is on the Windows box, it is converted to local (reliable) DDE where it can be transmitted to DDE-aware local processes.

To recap, NetDDE is unreliable. Don't use it. Don't confuse it with DDE either. DDE is old, but it is reliable, fast, and ubiquitous. Given that many programs offer no alternative interface, DDE can be the only viable choice for many applications. Even those programs that do offer an alternative interface usually also offer DDE.