Let’s begin with a little bit of history. “TINE” nominally is an acronym for “Three-fold Integrated Networking Environment”. (Unofficial acronyms include “This is not Epics”, if that is easier to remember.) The key word here is “Integrated”. Namely, TINE is multi-platform, where disparate platforms such as MSDOS, VxWorks, Windows, MAC/OS, any brand of UNIX or VMS can be integral parts of the control system without loss of generality. TINE is multi-protocol, where data exchange among the players can occur via any of the UDP, TCP/IP, or even IPX protocols. TINE is also multi-architecture, where data transfer can follow a client-server, publish-subscribe, producer-consumer, or publisher-consumer strategy. We shall explain what all of this means in a bit more detail below.
Next, let’s consider what we mean by a control system. In general, the players in a control system are distributed. This means that the control points are distributed processes which can be controlled from a central location. This will include diagnostics, monitoring and control as well as remote access to the distributed processes. Now having distributed processes communicate with one another, where say a PC in room A is displaying the data gathered by a VME crate in room B is one thing, but is a far cry from having a fully functional control system. What’s still missing is the “system” part of control system. For instance, there are central services, such as archiving, alarm processing, name resolution, etc. The control system will also have states, even if nothing else beyond “on” or “off”, this means that the control system is apt to offer such tools as finite state machines, sequencing and automation, where the system can be driven from state A to state B without human intervention.
The control system will also have to deal with synchronization of the distributed processes.
This means that all of the players will have to agree on a clock, and there should be some attention paid to the amount of jitter allowed in the individual process clocks. The control system will also have to maintain a strategy for security, and not just internet security, but also “system” security, where user A (although he’s a trusted user) should not be allowed to change setting B because the system is in the wrong state. The control system will also likely have to manage databases, meaning the general server-side configuration databases (hardware addresses, names, etc.) as well as the machine data, tying strongly to the archive system.
In order to trap faults and keep an overview of the system itself, the control system will have logging capabilities and statistics, of the control system itself as well as the system operation (those pie-charts, where one sees that in the last 24 hours the system was spending X percent of its time in state A, etc.)
The points mentioned above demonstrate that by having a control system, someone must be responsible for and give considerable thought to each of the following:
The players in a generic control system generally fit into the dichotomy of clients and servers.
A client is a player who wants to either monitor or control some element of the control system, who can exist anywhere (and in multiple instances), and is allowed to come and go as he pleases.
Clients are typically not contained in any central database, and those clients which are only allowed to run at one location are frowned upon (with a capital “F”) and should be re-written as servers.
It can be, however, that only one client is allowed to steer certain control elements at a time (acquiring an access lock), but this does not preclude others from monitoring the elements that he is steering.
A server, on the other hand is a player whose identity is known to the control system, and who is allowed to run only once (under a particular identity). Servers are typically connected to hardware and are given the task of monitoring and steering the hardware they are connected to. Servers can also be “middle-layer” servers, which are themselves clients to other servers, but have their own decision-making logic. The “important” servers in a control system should generally run all the time or be decommissioned. Regardless of whether a human is running a client program talking to the server, there are typically central servers, such as archive and alarm servers which are constant clients to those “important” servers. Servers (at least those with hardware) sometime go by names such as “Front End Controller” (FEC) of “I/O Controller” (IOC).
Many control systems talk about how many “layers” they have, which presumably means how many independent “software” layers there are from the bottom (the FEC) to the top (client). Generally all seven layers of the OSI model are there somewhere, and when push comes to shove, there are always bits and bytes coming in from the hardware, which get interpreted, calibrated, massaged, synchronized, or whatever, and end up being displayed at the “Presentation” layer. The presentation layer is one of the most important layers in the system, but is often overlooked by the control system staff, the point being that the system itself can be working ‘fine”, but if the end-users either can’t get what they want out of the system, or otherwise have to jump through hoops to get it, then the control system itself is going to take the blame.
So far so good. The above paragraphs apply equally to all control systems. What can TINE offer that the others can’t? (Actually, some of the control system you may have heard of can do some – but not all – of the things listed below).
For one thing, TINE has a small footprint. This is not true, for instance, for anything based on CORBA.
The TINE kernel still runs fine on MSDOS and can run embedded on Altera boards running NIOS.
TINE offers efficient data transfer under extreme scenarios. Namely, the “publisher-consumer” mode of data transfer can be used where large data payloads (e.g. video frames) need to be sent at high transfer rates to multiple clients. What this means is that the normal peer-to-peer data transfer between server and client, or rather publisher and subscriber, can be configured to be peer-to-network, using multicast (or broadcast if multicast is not available). Thus a client wishing data signals the server to publish via multicast. If the server is already doing this, then it doesn’t have to do it again! This allows TINE to offer video transmission in more-or-less real-time where the video frames are sent and received as they happen and are not buffered as in video streaming. Very few (and no non-commercial) systems besides TINE offer this capability
TINE offers a wide variety of data types for transfering data. These of course include the primitives (char, short, long, float, double, etc.) and also include fixed length strings such as NAME16 or NAME32, doublets such as FLTINT (float-integer pair) or DBLDBL (double-double pair), triplets such as FLTINTINT (float-integer-integer triplet) or NAME16FLTINT (16-char name-float-integer triplet, quadruplets such as FLTFLTINTINT (float-float-integer-integer), etc.
In addition to the standard set of data types offered, TINE allows user-defined "tagged" structures, where the developer can invent his own combination of primitive data types, register it, and use it as a data type object. Very few control systems offers this capability.
TINE offers an application programmer’s interface to a wide variety of platforms, so that it is generally easy to integrate it into an existing system. This includes LabView, C++, C, VB, MatLab, Python, Java, .NET and on your favorite platform!
TINE offers configuration tools and code-generating wizards for rapid development and configuration of servers.
TINE offers plug-and-play, which makes it easy for developers to introduce new servers into the control system.
If there is still an MS-DOS or Windows 3.1 machine which (for whatever reason) needs to be a part of the control system, TINE is about the only alternative there is.
1.5.8