Change of State (COS) Design Details

From AutomationWiki
Jump to: navigation, search

White Paper

Change of State (COS) COS

Understanding Subscriber Node COS Queue (SNCQ)

2014Mar – Peter Chipkin, Chipkin Automation Systems Inc.


DA = Data Array – A memory location in which the present values and other dynamic parameter values are stored.

Subscriber = A remote node interested in receiving periodic or event based update notifications. An active client subscribes and then waits for the active server to send it notifications while it listens in passive client mode.

COS Subscriptions - Trigger Rules relationships with DA's[edit]

For the purposes of the following notes

A COS trigger rule (CosTR) = a rule for publishing the data as well as a pointer to the device/md the data must be sent to.

Each element of each DA needs to be able to be connected to a set of CosTR’s.

A single DA element may be associated with more than one CosTR. This arises when a single DA element has been subscribed to from more than one source

A set of DA elements may be associated with a single CosTR. This arises when a subscription if for more than one element.

For example, the following arrangements may be possible.

Two single element CosTR's

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#2

One CosTR spanning a range

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1 CosTR#1 CosTR#1 CosTR#1

One CosTR applied to non-continuous DA elements

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1 CosTR#1 CosTR#1

Two CosTR's subscribe to same DA element

DA element 0 1 2 3 4 5 6 7


DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1
CosTR#2 CosTR#2 CosTR#2
CosTR#4 CosTR#4 CosTR#4 CosTR#4

and Therefore

It would seem sensible to have a list of CosTR's that are stored independently of the DA's and then point part of the DA structure to the list.

This is similar but not the same as responsible MD's (not the same because only one responsible MD for each DA element)

Adding a subscription is done the following way.

eg Add CosTR#1 to DAx:y

Add the CosTR#1 to the list of of CosTR's. (if an identical one exists then increment the instance count - don’t add a duplicate - this discussion may be irrelevant because the rule may be the same but why would the subscriber be the same ?) In the DA find element 'y'. Add an item to its list of CosTR pointers. The list of pointers may already exist because another CosTR may have been associated with DAx:y

If a CosTR is removed then decrement its instance count. If zero then we could remove it but what about the DA's pointing to the CosTR. We could make the pointing bi-directional or we could mark the CosTR as dead and leave it in place so that when a DAx:y is updated the pointer points to a dead rule and when this is discovered the DA removes the pointer.

How to define the Subscriber[edit]

A subscription consists of two elements

  1. CosTR’s (Change of State Trigger Rules)
  2. Publishing Information.

Say we DAx:y is updated in such a way that it triggers COS publishing. IN AR003 we have discussed the fact that the COS data gets sent to the Subscriber Node COS Queue (SNCQ ) which will manage the publishing.


What properties of the publishing driver need to be associated with the CosTR of DAx:y

At the very least an address need to be associated because when the data is published the publisher must send the updated DAx:y data and identify it with an address.

For example: Modbus RTU. You cannot just send data. You send a write message which contains a Data_Type, address, length and data. The length can be derived. The Data_Type could be derived but I suspect that the subscriber may want to specify this and certainly the address must be known in advance. Hence A subscription could read as follows: When DAx:y=1 then send this data as if it were the contents of binary input 10001.

Another example: The DA contains enough info: DAx:y sent by SMT only needs to send a message that contains the DA name, offset and length.

The point is this

Protocol dependent

Not always required.

COS Process[edit]

Configuration Stage[edit]

Configuration can be static (CSV) or dynamic. Both process result in the creation of connections, nodes, publishing rules and special MD like structures called Trigger rules.

Trigger rules define how the COS events are define and then in the MD part of the structure provide info on how to publish the data because they provide protocol, node, co0nnection, address and other related info.


Post Configuration Stage[edit]

When trigger rules are created, the kernel visits each DA structure to be watched and makes that DAx:y point to a set of trigger rules that are relevant for DAx:y


Data Events[edit]

When a da_put is called just prior to the update, the old value and new value are grabbed and a trigger rule processing function is called. For DAx:y each associated rules is inspected. If warranted, a SNCQ Q-item is created and added to the SNCQ (Subscriber Node COS Queue)


Publishing - SNCQ Idle[edit]

An idle task browses the Q. For each subscriber node it checks the bandwidth rules. If we have recently sent data and a new message would violate the bandwidth rules then the next node is processed.

If permitted then the publishing rules are applied to Q items for a node. (The Q may be in recovery mode and the publishing process is different from the note below). The Q item provides a pointer to a trigger rule which in turn provides an MD which can be passed to pex fast track writes.



Date Rev By Note
2014Mar10 1 PMC Created
2014Apr 2 SWS Added notes on COS Processing