In IoT “S” stands for security (c) one smart guy in Twitter
Weak security is a major problem of almost all modern IoT and IIoT/Industry 4.0 solutions. There’s usually nothing wrong when equipment state or shadow state is available for nodes in your configuration, as one of Industry 4.0 design principles is “Information transparency”.
However things change when we start talking about control. Allowing nodes to control each other and send action API calls is dangerous: if attacker get an access to information exchange point, he can destroy your business or even your life.
This article describes, how to install EVA ICS on Ubuntu or Debian. Actually it duplicates the information from EVA ICS installation docs, however is focused on Ubuntu with local mosquitto MQTT server, has minimal description and contains all required commands which could be just copy/pasted in console shell.
So let’s consider you have fresh Ubuntu install (I’ve used 18.04 LTS). What should be done, before we can launch EVA ICS easy-setup:
Install required OS packages
Configure local mosquitto MQTT server
Configure EVA ICS venv to skip building “heavy” numpy/pandas modules (we’ll use them from OS repository)
Primary EVA CLI tools are eva (./bin/eva) and eva-shell (./bin/eva -I or ./bin/eva-shell). Actually it’s a same program, which automatically starts itself in interactive mode (-I) when called as eva-shell and without any argument.
If command “uc”, “lm” or “sfa” is called without arguments, EVA shell will launch corresponding controller sub-shell, which’s equal to calling uc-cmd, lm-cmd and sfa-cmd directly.
You can execute a pack of several commands at once, separating them with “;” symbol, just like in a system shell:
state -p sensor ; state -p unit
The next very useful trick is command repeating. In real life, there’s a lot of examples, when you mount / setup some equipment and need to check its state every second to get the moment it start working correctly. To repeat the command in EVA shell , symbol “|” (pipe) is used
EVA ICS doesn’t use thread pools in core, number of threads is always fixed (except LM PLC macros), grows together with node configuration, and should be controlled by system administrator/integrator. Majority threads “sleep” until they get an event and don’t produce additional load.
After controller start, core launches several system threads (garbage collectors etc.), plus threads for each item:
Two update threads (update scheduler + update processor) per each unit, sensor and lvar
One action thread per each unit
Two update threads for PHI module, if loaded with update=X parameter
One notification queue thread for each notifier
One thread for UC UDP API, one thread for UC SNMP trap handler (if enabled).
LM PLC launches a single thread which handles queue for scheduled macro exections. After the execution, each macro has its own thread, number of threads for macros isn’t limited by PLC.
Also, each LM PLC logic cycle has own thread as well
If MQTT transport is used for API calls between nodes – one thread per API call (max lifetime = server.timeout)