org.eso.ias.types
Members list
Type members
Classlikes
Companion object
Companion object
Attributes
- Companion
- class
- Supertypes
-
class Objecttrait Matchableclass Any
- Self type
-
Identifier.type
The immutable Identifier is a recursive data structure composed of a unique ID plus the ID of the parent. The ID, in turn, is a couple with unique identifier plus the type of the identifier.
The immutable Identifier is a recursive data structure composed of a unique ID plus the ID of the parent. The ID, in turn, is a couple with unique identifier plus the type of the identifier.
The identifier (id,type) is the unique identifier of an element of the core. Even if not intuitive (and strongly discouraged), it is possible to have different elements like for example a DASU and an ASCE with the same ids because their types differ.
The parent of an item is the "owner" of the item itself:
- the owner of a monitor point is the monitored system that produced it
- the owner of a component is the DASU where the component runs
- the owner of the DASU is the Supervisor where the DASU runs
- the Supervisor has no owner, being a the top level of the inclusion
Another way to think of an Identifier is a way to describe the IAS components that contribute to generate a IASIO. The identifier of all the other IAS components can be deducted in the same way. There are 2 possible ways to generate a IASIO: getting a monitored value of alarm from a remote monitored system and inject into the core or the output of a ASCE/DASU.
In the former case the IAS components that collaborate to produce the IASIOs are the monitored system, the plugin who gets the value, the converter that translated the value in a IAS data structure. In the latter case the components that collaborate to generate a IASIO are the the Supervisor, the DASU and the ASCE.
There are therefore only 2 possible types of identifiers, for the 2 cases described upon:
- Monitored system->->Plugin->Converter->IASIO
- Supervisor->DASU->ASCE->IASIO
The constructor checks if the Identifier that is going to build is compatible with the type of the passed parent.
Dedicated auxiliary constructors support the generation of replicated items, being them ASCEs, DASUs or IASIOs, from and identifier and the the given instance number by appending to the passed ID, a suffix followed by the number of the instance and the suffix. The constructor does not make any check to ensure that the passed instance number matches with the definition of the template in the CDB. The method buildFromTemplate(String, Option[Int]) builds an identifier from a template.
This definition of the identifier shows the deployment because the parentID depends on where/how an element is calculated deployed. The id of an item is supposed to be unique in the system: the deployment information is mostly useful for debugging as it allows to follow the computation path of a IASIO.
At run-time, to avoid traversing the parents, a unique ID is generated in form of a string.
The class is Iterable by definition as it contains a reference to the Identifier of the parent.
Value parameters
- id:
-
The not null nor empty identifier
- idType:
-
The type of the identifier
- parentID:
-
The identifier of the parent
Attributes
- Constructor
-
Builds an identifier with a ID, a type and its parent
- Companion
- object
- Supertypes
-
class Objecttrait Matchableclass Any
A InOut holds the value of an input or output of the IAS. Objects of this type constitutes both the input of ASCEs and the output they produce. They are supposed to live into a ASCE only: their representation in the BSDB is the IASValue[_].
A InOut holds the value of an input or output of the IAS. Objects of this type constitutes both the input of ASCEs and the output they produce. They are supposed to live into a ASCE only: their representation in the BSDB is the IASValue[_].
The type of a InOut can be a double, an integer, an array of integers and many other customized types.
The actual value is an Option because there is no value associated before it comes for example from the HW. Nevertheless the InOut exists.
If the InOut is the input of a ASCE, it has the validity received from the IASValue in the fromIasValueValidity. Otherwise the validity depends on the validity of the inputs to the ASCE and is stored in fromInputsValidity. At any time, only one Option between fromIasValueValidity and fromInputsValidity must be defined: this invariant, can also used to recognize if a InoOut is an output of the ACSE.
Value parameters
- convertedProductionTStamp
-
The point in time when the converter generated the value from the data structure rceived by the plugin
- fromIasValueValidity
-
: The validity received from the BSDB (i.e. from a IASValue) It is None if and only if the value is generated by ASCE and in that case fromInputsValidity is defined
- fromInputsValidity
-
the validity inherited by the inputs It is defined only for the outputs of an ASCE and in that case fromIasValueValidity must be None
- iasType:
-
is the IAS type of this InOut
- id
-
: The unique ID of the monitor point
- idsOfDependants
-
the identifiers of the dependent monitor points i.e. the identifier of the inputs if this InOut represents a output empty otherwise
- mode
-
: The operational mode
- productionTStamp
-
The point in time when the value of the InOut has been produced by a plugin, a DASU or a core tool
- props
-
additional properties if any, otherwise empty
- readFromBsdbTStamp
-
The point in time when the value has been read from the BSDB
- readFromMonSysTStamp:
-
The point in time when the value has been read from the monitored system (set by the plugin only)
- receivedFromPluginTStamp
-
The point in time when the converter received the value from the plugin
- sentToBsdbTStamp
-
The point in time when the value has been sent to the BSDB
- sentToConverterTStamp
-
The point in time when the plugin sent the value to the converter
- validityConstraint
-
allows the ASCEs and the DASUs to restrict the evaluation of the validity to a subset of inputs As the IASValue read from the BSDB have no inputs, validityConstraint is defined only when fromInputsValidity is defined but not the other way around
- value
-
: the value of this InOut (can be empty)
Attributes
- See also
-
isOutput() A IASIO can be produced by a plugin, by a DASU or a core tool; independently of the toll that generated the value, the timestamp is saved in the productionTStamp. The tool that generated the value can be identified by the recursive Identifier of the inOut. A property of the InOut contains the list of the dependent monitor points. Only an output can have dependent monitor points i.e. the InOut in input to the DASu that are needed to produce the ouput. The InOut in input have an empty set of dependant monitor points.
InOutis immutable.IASType
- Companion
- object
- Supertypes
-
trait Serializabletrait Producttrait Equalsclass Objecttrait Matchableclass AnyShow all
The validity of an alarm or monitor point value is a measure of how much the value reflects actual situation of a monitored system.
The validity of an alarm or monitor point value is a measure of how much the value reflects actual situation of a monitored system.
Basically, if the value is produced propagated in time then it is reliable otherwise is unreliable.
An invalid value or alarm is displaied with a proper color coding (or other visualization strategy) to let the operator aware that the information provided by the IAS might not reflect the actual situation.
The Validity is immutable
Value parameters
- validity
-
the validity
Attributes
- Companion
- object
- Supertypes