Installing EVA ICS on a production machine without the Internet connection is tricky is pretty easy, but Python virtual environment should be manually prepared. Another option is to mirror pypi.org repository, but it requires about 120GB of disk space and isn’t recommended, unless used for another company needs.
In this article we will explain how to install EVA ICS on Debian / Ubuntu machine in the offline mode.
When we started development of EVA ICS, asynchronous programming just started to be popular. EVA ICS 3 core is thread-based. It works pretty well, doesn’t produce too much memory/CPU load, but it can work even better.
Let me introduce atasker library. This is free, open source Python library, which will solve many problems as in EVA ICS core, as in any other similar project.
New Driver API v5 in EVA ICS 3.2.2 brings important improvement: now Physical Interface modules can support extended unit state (status + value). To test and demonstrate this feature, we’ve made PHIs for 2 popular LED controllers: Philips HUE and Nanoleaf. Everyone likes playing with LEDs, even industrial guys )
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)