Each value stored in the Cascade DataHub is called a point. A point has the following attributes:

The Cascade DataHub does not require you to configure the names or types of data points you will be using in your system. If your program writes a data value to the DataHub and the point does not exist, the DataHub will create the point. If a program registers for exceptions for named points that currently do not exist in the DataHub then the DataHub will create those points and register the client program at the same time. If a program tries to read the value of a point that doesn't exist in the DataHub, then the DataHub will create the point and return a default zero value with a zero confidence to the client program.

The DataHub does not limit the size of a point data message. The only limits are those imposed by the operating system. This limit is 64000 bytes in QNX using SRR, 128000 bytes in Linux using the SRRIPC Module, and unlimited for TCP. Bear in mind that very large values will take more time to be transmitted over a network.

Typically, the Cascade DataHub is started before other application modules. Then, other tasks are started that communicate with the DataHub (to request exceptions, send data, or both). Memory (RAM) is allocated for the points as they are created by the DataHub.

It is not possible to directly delete points from the DataHub. Should a point no longer be in use by any participating program, when the DataHub is shut down and restarted, the point will no longer appear.

The normal way to receive data is to have your program register for an exception on a data point. Once you have registered for an exception, the DataHub will send you an update whenever the value for that point changes.

The waiter utility registers for exceptions with a DataHub and displays any new point values that it receives. The source code for this example will help you develop applications that effectively utilize the DataHub. See waiter for details about the syntax for waiter, and see its source code in the Registering for exceptions from the Cascade DataHub appendix of the Cogent C API manual.

The Cascade DataHub divides data into domains. This provides namespace separation and avoid conflicts when working with multiple third-party data sources. In addition, using domains for a large network can significantly reduce network traffic. All references for point values that reside in a domain other than default are referenced using a domain prefix of the following format: domain:pointname

The Cascade NameServer assigns the DataHub a name for each domain. These names are used for communication with other programs, and can be viewed using the nsnames command. For example:

[sh]$  datahub -d test1 -d test2
[sh]$  nsnames
Name      Domain Queue      NID PID
/dh/test1 test1  /dh/test1  0   13446
/dh/test2 test2  /dh/test1  0   13446

In some cases the DataHub will only register its name with a process ID on it. This is useful if you don't specify a domain with the -d option or in the configuration file, and the DataHub is acting as a TCP master (see below). For example:

[sh]$ datahub
[sh]$ nsnames
Name        Domain  Queue      NID PID
/dh/13440   default /dh/13440  0   13440
/dh/default default /dh/13440  0   13440

As clients ask for points in various domains, the DataHub will register the appropriate names with nserve, if possible. If you have more than one DataHub serving the same domain name, only the first one will be allowed to register the /dh/domain name with nserve.

Within a domain, data can be arranged hierarchically as assemblies, subassemblies, attributes, and properties. Each assembly can have zero or more attributes and zero or more subassemblies, and each attribute can have zero or more properties. Subassemblies can have subassemblies. You can think of assemblies and subassemblies as branches in a tree, and attributes as the leaves. Here is an example of what a tree might look like:

Domain
    Assembly
        Subassembly (zero or more)
            Attribute  (zero or more)
                Property  (zero or more)
        Attribute...
        Attribute...
        Attribute...
            Property...
            Property...
            Property...
        Subassembly
            Subassembly
                Attribute...
                  Property...
                  Property...
            Attribute...
            Attribute...
                Property...
    Assembly...

and so on.

The written syntax for all of these levels uses a dot (.) to divide the names, rather than a colon that was used for the domain name. Hence, the syntax of point in a property in an attribute in a subassembly in an assembly in a domain would be:

domain:assembly.subassembly.attribute.property

Properties describe the attributes in more detail. An attribute can have a default property such that if you interact with the attribute point directly you will in fact be interacting with its default property. For example, an item might be plant.temperature, with properties value, highlimit, units. This would create 4 tags:

The tags:

are aliases of one another. Both refer to the default property of plant.temperature. If you specify no property at all for an item, the item takes on the default property.

It is common for attributes to contain the same type of information. For example, all temperatures in a system are likely to share units, high alarm level, and value. To avoid repeating this information for each and every temperature in the sytem, we use a type. A type is the prototype, or class, of an attribute. You define a type and its properties first, and then define attributes of that type on assemblies. When the assembly is instantiated, its attributes are instantiated by creating an attribute and then assigning the properties to it that are associated with the attribute's type.

There is an alternative to using types and attributes as described here, a private attribute. A private attribute provides a one-command means of creating an attribute on an assembly without having to define a type. However, this means that the attribute properties cannot be shared across more than one attribute in the assembly or in other assemblies. This is normally only used internally with machine-generated hierarchies. In most cases it is better to use types and attributes.