Monitoring and Control ModelΒΆ
Yamcs implements a fairly traditional Monitoring and Control Model. The remote system is represented through a set of parameters which are sampled at regular intervals.
Yamcs assumes that parameters are not sent individually but in groups which usually (but not necessarily) are some sort of binary packets. Yamcs supports basic parameter types (int, long, float, double, boolean, timestamp, string, binary) and also aggregate types (aka structs in C language) and arrays.
Parameters can either be received directly from the remote device or can be computed locally by algorithms. Algorithms in Yamcs can be implemented in Javascript or Python. Other languages that have JVM based implementations could also be supported without too much trouble.
Following XTCE conventions, Yamcs distinguishes between:
- telemetered parameters
coming from remote devices
- derived parameters
computed by algorithms inside Yamcs
- local parameters
set by end-user applications
- constant parameters
constant values defined in the mission database
In addition to these XTCE-inspired parameter types, Yamcs defines:
- system parameters
parameters generated by components inside Yamcs
- command and command history parameters
Specially-scoped parameters that can be used in the context of command verifiers.
The parameters have limits associated to them and when those limits are exceeded, an alarm is triggered. The limits can change depending on the context which represent the state of the remote device. The context itself is derived from the value of other parameters.
An operator is informed of the triggered alarm in various ways depending on the end user application connected to Yamcs (e.g. red background in a display, audible alarm, SMS, phone call, etc). After understanding the problem, the operator acknowledges the alarm, which means that it informs Yamcs that the alarm will be taken care of. This action - depending again on the remote end user application connected to Yamcs - means that other operators are not bothered anymore by the alarm.
After the alarm has been acknowledged and the parameter goes back into limits, the alarm is cleared which means it is not triggered anymore. Before the alarm is acknowledged by an operator, it will stay triggered even if the parameter goes back into limits. An exception to this case is auto-acknowledging alarms which are cleared automatically when the parameter that triggered them goes back in limits.
As parameters are expected to be sampled regularly, they also have an expiration time. After the time is exceeded, the parameters become expired. This means that the state of the remote device is considered unknown.
The remote device is controlled through the use of (tele)-commands. A telecommand is made up of a name and a number of command arguments. In order for a command to be allowed to be sent, the command transmission constraints (if any) have to be met. The constraints are expressed by the state of parameters (e.g. a command can be sent only if a subsystem is switched on). Some commands can have an elevated significance, which may mean that a special privilege or an extra confirmation is required to send the command.
Once the command has been sent, it passes through a series of execution stages. XTCE pre-defines a series of stages (TransferredToRange, SentFromRange, Received, Accepted, etc). Yamcs does not enforce the use of these predefined stages, the user is free to choose any number of random stages. Each stage is associated to a command verifier. This is an algorithm that will decide if the command has passed that stage or not. It is also possible to specify that the stage has passed when a specific packet has been received.
The command text (command name and argument values), the binary packet (if binary formatted) and the different stages of the execution of the command are recorded in the command history.
Yamcs does not limit the information that can be added to the command history. This can be extended with and arbitrary number of (key, timestamp, value) attributes.