AOS scripting

This layer makes it possible, as indicated, to answer the problems of automation of an installation. It is essentially based on a language: AOS. The latter is an industry-oriented programming language. It was created in such a way as to allow Nodergy users not familiar with the Java language to have a higher abstraction layer in order to write their programming scripts for industrial PLCs. AOS is first and foremost a syntax. This is all of his writing rules, which will be described through several examples. There are four main categories of AOS objects: threads, variables, actions, and events.

AOS Threads

To begin with, an AOS script must declare a thread. This is its entry point, where code execution begins. You can declare as many threads as you want, but you will need at least one to start program execution.

A thread is declared as follows: ThreadName - The description of the thread: [thread] {start: startFeed; }; The start parameter is the thread start action that will be executed when the program is started. The actions of the AOS language will be defined below. For this reason, we must pay attention to the content of the latter. Typically, it would not be desirable to actuate actuators on the machine prior to having previously verified a certain number of parameters / conditions. Thus, even if AOS offers great freedom in the creation of automation scripts, a certain number of rules of good practice must be respected in order to better prevent any unwanted behavior of the controlled system. We will come back to this in more detail later.

AOS Variables

Once the thread is declared, the user can define one or more variables. These are very useful when it comes to modifying a function parameter in real time. For example, during a regulation, one wishes to be able to assign a new value to the proportional component of the PID and that the change is instantly taken into account.

For that, it will be necessary to declare a global variable at the level of the file AOS (by convention, one declares them at the top of this last), in the following way: variableName - description of the variable: [variableType] {preset: initialValue; rights: R; };

the type of variable is to choose from the following elements:

• Boolean
• Double
• Enum
• Float
• Int
• Feature
• Shorts
• String

Note that the type "enum" corresponds to an enumerable (a list of options), and it is thus necessary, in addition to the parameters preset and rights, to define the item parameter and to assign to it the list of the admissible values ​​by the variable.

Example: stopStatus - Enumerable describing the different status of the stop thread: [enum] { preset: STANDBY; items: STOPPING, STOPPED, ERROR, EMERGENCY_STOPPING; rights: R; };

the "preset" parameter corresponds to the initial value that is assigned to the variable. The "rights" parameter determines whether the field is of type "Read", "Write" or "Read and Write". We will not be able to write a value on a field of type R. They are therefore indicators. Conversely, a field of type W or RW is modifiable. Finally, note that the float type also has a specific attribute, the "unit" parameter, which can optionally assign (this field is optional) a unit to the created variable. Example:

rPumpPIDSetpoint - Setpoint to be reached when operating the PID of the refrigerant pump at rated speed: [float] {preset: 10; rights: RW; unit: degC;};

AOS Actions

actionName - description of the action: [actionType] {parameter1: value1; parametre2: value2; };

The name of the action is the identifier of the latter. He must be unique. It is specified by the user. It is optional. However, if the action does not have an identifier, it will not be possible to call it in another place of the code, typically for a switch. The description of the action is the text to understand the purpose of the latter, it is intended for code reviewers and has an informative value. Unlike the name of the action, the description is mandatory. The code will not compile in case of no description. Each line must be commented. The type of the action is the keyword referring to an action defined in AOS (see below). This field is required and case-sensitive. Parameters are action-specific (see below). The values ​​they can take are too.

AOS Events

An event is used to attach to a method the detection of a particular event occurring during the execution of a method. This AOS object is constructed in such a way that the triggering of the associated action is immediate. It is attached to a method. Thus, an event will always trigger in the context of the execution of the AOS action to which it is associated (or in one of the daughter actions). Example:

The name of the event is the identifier of the event. He must be unique. It is specified by the user. It is obligatory.

The description of the event is the text to understand the meaning of the latter, it is intended for code reviewers and has an informative value. This field is required. The code will not compile in case of no description.

"Event" is the keyword referring to the event type in AOS. This field is required and case-sensitive.

The "on" parameter defines the condition to be checked to trigger the event. This is a Boolean expression that is checked before each "execution round" of the action in which the event is encapsulated. This parameter is required.

The "do" parameter defines the action to be performed in case of a verified condition.

The events are used for example in the context of "listening loops", which are written to monitor certain variables of the installation (typically the pressures in the context of a safety loop). They allow, for example, to react immediately when the monitored variable reaches an alarming value.

AOS Implementation details

Behind the scenes, the operation of the AOS language is based on the implementation of programming logic written in Java, and designed to limit the impact of the AOS code on the available computational resources. Indeed, if the written AOS code is particularly complex (typically in the case of a large number of actions nestings), we do not wish to observe a significant slowdown in the execution of the program (because it must follow a tempo imposed by the physical reality of the operation of the installation). For this reason, the language AOS, and more generally the layer N1 which encapsulates it, are based on a general principle, which is that of the discretization of time.

Thus the N1 is "clocked", and executes a new step of its script every 250 ms (value of the time step by default between two executions). This point is important: it explains why there may be a gap between when an action is supposed to run and the actual moment it actually runs. However, this offset remains low, and acceptable given the operating rates of industrial machines driven by the N.

Associated with this discretization of time, a second major principle of the N1 layer must be described here: it is the principle of the single thread. It is like managing, in a thread (a thread, in java, is a "thread of execution", in which one can play a program independently and isolated, and especially concomitant with the other threads launched in parallel) unique, the simultaneous execution of several actions. This avoids the creation of a new thread with each new action to be played in parallel with others. A thread is indeed resource intensive, and the accumulation of too many of these may cause an error during the execution of the program. This principle does not, however, prevent the simultaneous execution of several actions. Indeed, with each new "run of execution" of the program written in AOS at the level of the N1, each of the actions to be played in parallel executes its own "tour", in a completely independent and concomitant way to the others.

What to remember: The execution rate of the program and the architecture of the java layer on which the N1 level and the associated AOS language are based imply limitations in the writing of the AOS code. Typically, the time scale is defined at 250 ms, it is useless to define times inferior to this value, for example a delay with a duration of 100 ms will have no sense, since the script will actually wait 250 ms between the start of the delay and the next turn (which will mark the end of the action). These elements must be kept in memory when writing code in AOS.