Every message on a VSCP segment can be seen as an event. To be of any use to anyone a decision has to be taken on what to do as a result of the event. This is done in a decision matrix, which is a standardized way to write the rules that take care of events. To get something done when a specific event is detected some sort of action mechanism is needed.

The event-decision-action model or eda-model is the way we look at the functionality of a VSCP-node. First of all a node can be a level I or level II node. A level I node can perform actions from all level I messages. A level II node can handle both level I and level II messages. In fact when we define rules we define them at the highest level.

To be able to build a software model that is common for several device/machine/situation types and environments we have to make a model to suit the typical control situation. The model is very simple and is also very easy to implement on different target environments.

Something happens that triggers some kind of input. This could be the elapse of a timer, a delivered temperature reading, a triggered fire alarm etc. Without this state there is nothing to do. We call this state the EVENT - state.

If an event occurs we may react in some way to this happening. This reaction comes after a decision about if and how the event should be handled. We use a decision matrix to control the logic of our decisions. Every element in the decision matrix handles one event and performs one action. A decision matrix element is also capable of generating events and can in this way perform several actions on the behalf of one event.

The action is the function, thread, procedure, method or other functionality that should be carried out as a result of an event.

The states represented by EVENT + DECISION + ACTION are treated as one transaction. All steps must be handled for the transaction to be marked as completed.

So when you describe the functionality of a VSCP-node you say

• This node reacts on the following events.
• This node can perform the following actions.

To make the node a useful piece of equipment it needs a decision matrix. This matrix can be implemented with no possibility for a user to change it or it can be undefined and left for the user to specify.

In resource-limited environments, such as a microprocessor, the previously discussed matrix format takes up to much space and a more resource friendly format is therefore defined. Here the class + type bytes formats the event.

This matrix has no trigger for data values. This has to be done internally by the application using user defined codes.

A matrix row consists of 8 bytes and has the following format

Oaddr is the originating address. We are only interested in messages from the node given here. 0×00 is segment controller and 0xff is a node without a nickname. If bit 6 of flags is set oaddr will not be checked and events from all nodes will be accepted.

The enable bit can be used to disable a decion matrix row while it is edited.

The zone and use subzone bits can be activated to have a check on the zone/subzone information of an event. That is the zone/subzone of the machine must match the one of the event to trigger the DM row.

A class that should trigger this decision matrix row is defined in class-mask and class-filter with bit eight for both taken from the flags byte.

The following table illustrates how this works

Think of the mask as having ones at positions that are of interest and the filter telling what the value should be for those bit positions.

• So to only accept one class set all mask bits to one and enter the class in filter.
• To accept all classes set the mask to 0. In this case filter don't care.

A type that should trigger this decision matrix row is defined in type-mask and type-filter with bit eight for both taken from the flags byte.

A similar truth table as for the class-mask/filter is used.

This is the action or operation that should be performed if the filtering is satisfied. Only action code 0×00 is predefined and means No-Operation. All other codes are application specific and typical application defined codes could do measurement, send predefined event etc.

A numeric action parameter can be set and its meaning is application specific.

The number of matrix rows are limited on a micro controller. The control class has an event defined that gets the number of elements in the matrix and the location of the matrix in the register model of the node (Get Decision matrix info, CLASS1.PROTOCOL, Type=33).

The matrix information is read and written with the standard read/write control functions. And is placed in the standard low register range (< 0×80) or in an optional page in this area.

Note that there is no demand that a node implements a decision matrix. If not implemented the Get Decision matrix info just returns a zero size.

A special paged feature is available for the decision matrix to save register space. If the offset for the decision matrix is 0×80 - 8 i.e. starts at 0×78 (120) it is implied that the register position just below 0×77(119) contains a register that is an index to the active DM.

Method CLASS1.PROTOCOL TYPE=32 is used to fetch decision matrix information for a specific node.

It is important to note that the decision matrix can contain any number of lines for a specific event element. So one incoming event can trigger many actions.

Events are marked as handled when the action thread is started. This can be bad in some situations where the event chain is dependent on the action to complete its task before any new work is done. In this case it is better to continue the event chain by posting an event from the action thread instead of setting the following event as a next event in the decision matrix.

The decision matrix structure gives us the freedom to implement events that perform:

• Exactly one action.
• Several actions.
• Several actions in a sequence.

To understand how the decision matrix is updated one needs to understand how it is set up. Each line of the matrix is built from a table of entries of the following form:

where the action-param has device specific length.

This is a bit mask, which has ones at the bit positions of the event that is interesting. So 0xffffffff makes all messages interesting. Class is in the high word. Type is in the low word. For a truth table see the class-mask for Level I decision matrices.

This is a bit mask, which tells the vaule for bits that is of iinterest. Class is in the high word. Type is in the low word. For a truth table see the class-mask for Level I decision matrices.

Specific node implement ions decide how to interpret bits or not. Just some or none of the bits can be used if that suits the implement ion.

This is the what should be carried out to make this action happen. This is a 16-bit cod that is application specific. 0×0000 is the only code that is predefined as no operation.

This is a variable length text-string/binary array that can contain parameters for the action. Format is application dependent. Can be omitted if no parameters are used.

A decision matrix row is 14 bytes plus the size of the action parameters.

A special paged feature is available for the decision matrix to save register space. If the offset for the decision matrix is 0×80 - dm-row-size (a DM row aligned to the upper register border) it is implied that the register position just below, 0×80 -dm-row-size - 1, contains a register that is an index to the row that has its first byte at 0×80 - dm-row-size.

The index byte is used to select rows and the selected row is available from the byte after the index byte to the 0×80 border.

Method CLASS1.PROTOCOL TYPE=32 is used to fetch decision matrix information for a specific node. Byte six of the response tells the actual size for a decision matrix row.

The Level II Decision Matrix has no entry for originating address. The action parameter field can be used for this information if needed.