Extended Tags

This message allows the creation and con guration of up to three sets of information tags to be used by an event having the Message ID quali er set to A, B or C. This will make such an event generate an EV reporting message with extra information tags as described on the EV message section.

For example, to set event 49 to send en extended-EV message that includes the vehicle’s acceleration, the number of GPS satellites in view and the state of distance counter 05 whenever the vehicle’s speed goes beyond 55 mph: Defi ne the event. Set it to use extended-EV format A
>SED49NA0;S00+< De fine extended-EV format A to include the required tags >SXAEFA;AC;SV;CV05< To delete the extended-EV reporting format send >SXAEFAU<


A valid TAIP message without the opening (>)and closing (<) delimiters. Several TAIP actions can be de fined on a single event. There are two valid messages to defi ne the action.’ACT=’ which will make the event to be sent both through the serial port and over the air and’XCT=’ that will only send the event through the serial port. See the following examples. Actions refer to the things that you want to execute automatically as part of an Event Definition. Example: >SED00NV0;F00+;ACT=SSSXP21< The action above is ACT=SSSXP21, this means that when F00+ (Ignition is ON) we are going to automatically execute SSSXP21. There are two types of actions ACT & XCT, when the Event Handling|Message Routing is Silent – we do not worry about which one to use. When the Event Handling|Message Routing is Normal – the following applies: ACT = Means that the response to the Action: >RSSXP21;ID=356612021234567< is sent to the Destination Points defined in the Event’s Destination Address. XCT = Means that the response to the Action: >RSSXP21;ID=356612021234567< is NOT sent to the Destination Points, it’s still executed, but silently (meaning it’s not visualized on the server).

Event Trigger

A trigger is determinated with the logical combination of several situations (also called signals). A logical combination is basically an equation (speci fically: a boolean equation) that combines signals (situations) with the logical operators AND, OR and NOT. In Syrus, these boolean equations use the postfi xed notation, meaning that the operator is at the end of the signals to be evaluated. When more than three signals are being evaluated, a logical operator must be inserted every two signals in the equation. These are some examples of the postfi xed notation syntax:
A or B → AB||
A and B → AB&
A and B and C → AB&C&
To determine how the signals will trigger the report a plus (+) or minus
(-) sign is added at the end of the equation. A plus sign (+) indicates that
the report is generated when a signal or an equation becomes \true”. Consequently, a minus (-) sign indicates that the report is generated when the signal or the equation becomes \false”.

When A or B becomes true →AB||+

When A and B and C becomes false →AB&C& –

If the report must be generated when one signal becomes true and another becomes false one of the signals must be negated using the boolean operator not. Either the plus or minus sign can be used, but for it is easier to understand the equation when the plus sign is used.
When A becomes “true” and B becomes “false” →A!B&+

Boolean Logic

Logical operation used to combine signals:
&: AND
|: OR
!: NOT


As described in the previous section, the event machine takes actions like
reporting or switching outputs whenever a user de fined trigger goes off . This trigger is confi gured by the user with the logical combination of situations.

A situations makes reference to a vehicle state which is in fact represented by signals and their state. Syrus’ signals are of boolean nature, meaning that they can only take one of two possible values: true or false. Signals and the logical operators AND, OR, NOT are used to create logical equations to form events’ triggers.
By using the SS TAIP message a signal’s state can be consulted, and de-
pending on the signal’s type, this command can be used also to change the signal’s state.

Note: Signals’ names always have three characters.


Some examples about the use of the event machine are presented next.

Configuring two events on the Event Machine to generate an ignition report:
The ignition ON event may be defined as:

>SED18NV4;F00+< And the Ignition OFF event: >SED19NV4;F00-< Both events’ routing actions indicate that the destination of the report is the DA 4 and that EV is the reporting message to generate. Both events use a simple trigger consisting of a one-signal-only condition, F00 which is the vehicle’s ignition signal. Configuring an event that uses two signals: For this example we will use signal S00, which is associated with a speed limit and signal J00, which is associated with a heading delta. The event will be triggered when both signals are true, meaning that the vehicle exceeded the speed limit while making a turn greater than the heading delta defined: >SED05NV0;S00J00&+<

Destination Address (DAs)

A Destination Address is a user-de fined group of Destination Points. This
enables some reporting commands to route their report to several destinations at the same time with a single de finition. Up to 10 (0 to 9) DAs maybe de ned. Refer to the DA message for more information. This command enables the user to group a list of DPs and/or a range of DPs.
The main use for DAs is on the routing options of an event de nition. The
Event Machine section gives more information about this. What should
be clear on this, is that a report generated by an event is always sent to a
DA, not to a single DP. For this reason DAs make part of the minimum
con guration required by the unit. Some examples of DAs’ de nitions are:

1. Defi ning DA 5 as the group containing DPs 04, 06, 10 and 15:
>SDA5;P04,P06,P10,P15< This will make any event using DA 5 as Destination Address on its routing options to send the same report to the IP host 04, IP host 06, phone number 10 and the unit’s serial port. Such an event could be de fined as: >SED23NV5;TD1+< 2. Defi ning DA 8 as the group containing DPs 00 to 03, 07 to 09 and 14: >SDA8;P00:P03,P07:P09,P14< 3. To delete a DA de finition: >SDA8U< Note: You can always de fine a DA containing a single DP so you can send a single report to a single destination. For example: >SDA3;P01<

Message Identifier

Alphabetical characters used to identify messages. The letter V is the standard’s one.

This message allows the creation and configuration of up to three sets of information tags to be used by an event having the Message ID qualifier set to A, B or C. The message has the following format:


A: Identifier of the extended-event format being set or consulted. The valid identifiers are: A, B or C.
[BBB…]: Information tag. Enter each tag separated by a “;” character.For more information about tags please refer to Syrus manual.
For example:

To set event 49 to send an extended-event message that includes the cell information, the number of GPS satellites in view and the state of counter 05 whenever the vehicle’s speed goes above 55 mph:

Define the event. Set it to use extended-event forma

>SED49NA0;S00+< Define extended-event format A to include the required tags >SXAEFA;CF;SV;CV05< To delete the extended-event reporting format >SXAEFAU<

Event Handling|Message Routing

Message routing:
N: Normal. Route the Event Message to the speci fied Destination Address.
X: Serial Port. Route the Event Message to the unit’s serial port only.
S: Signal only. Do not generate an Event Message. The event’s signal still follows the event’s state.
U: Undefi ned. Delete the event’s de finition.

Event Number

Also referred to as the Index, they are unique for every event and can be from 00-99 events.

Event Definition

Event Definition

The Syrus 1 has 70 events and Syrus 2 has 100 events available for the user to confi gure. They may be de fined all at once in a con figuration script or they me be individually de fined at any moment as the user adds/removes functionality. The actual events’ de nitions of the unit may be consulted with the TAIP message >QED<. This will have the unit deliver the con figuration state of all events. An example of the returned confi guration on the TAIP console is: >QED< >RED00NV0;A00TD0&F00&+< >RED01NV1;A00!F03&TD1&F00&+< >RED02XM0;F03!TD2&F00&+< >RED03NV2;G00+< >RED04NV0;A00TD3&F00!&+< >RED05NV1;A00!F03&TD3&F00!&+< >RED06XM0;F03!TD3&F00!&+< >RED07NV0;A00U00&+;ACT=SSSU000< >RED08NV1;A00!F03&U00&+;ACT=SSSU000< >RED09U< >RED10NV0;A00U01&+;ACT=SSSU010< >RED11NV1;A00!F03&U01&+;ACT=SSSU010< >RED12U< >RED13U< >RED14U< >RED15U< >RED16U< >RED17U< >RED18U< >RED19U< >RED20NV0;A00C02&+< >RED21NV1;A00!C02&+< >RED22XM0;F03!C02&+< >RED23U< >RED24U< >RED25U< >RED26U< >RED27U< >RED28U< >RED29U< >RED30U< >RED31U< >RED32U< >RED33U< >RED34U< >RED35U< >RED36sV0;S00-;ACT=SGC02U< >RED37sV0;S00+;ACT=SGC02TC00010< >RED38U< >RED39U< >RED40sV0;F00+;ACT=SSSU001< >RED41sV0;F00-;ACT=SSSU011< >RED42U< >RED43U< >RED44U< >RED45U< >RED46U< >RED47U< >RED48U< >RED49U< You can see some events having a user-de ned TAIP action, diff erent routing options and many undefi ned events (having a \U” (for undefi ned) after the event ID). For more information on how to interpret this reading as well as how to create such con figuration refer to the ED message.