eva-ics / eva4 Goto Github PK

View Code? Open in Web Editor NEW

71.0 3.0 7.0 8.13 MB

open-source platform for industrial and home IoT

License: Other

Makefile 0.28% Rust 75.16% Shell 2.41% Python 15.74% HTML 2.59% TypeScript 1.95% JavaScript 0.02% C++ 1.68% C 0.18%

eva4's Introduction

EVA ICS v4

EVA ICS® v4 is a new-generation Industrial-IoT platform for Industry-4.0 automated control systems.

The world-first and only Enterprise automation platform, written completely in Rust: extremely fast, secure and stable.
Allows to handle millions of objects on a single node.
Provides the real control of objects: actions and various automation scenarios can be executed, both locally and remotely.
The new v4 micro-core architecture is completely scalable and allows to build complex setups for any industrial needs: factories, power plants, military sector etc.
Built-in API and servers for web SCADA applications.
Real-time event replication and interaction between cluster nodes and web HMI applications.

Installation

Read https://info.bma.ai/en/actual/eva4/install.html

Technical documentation

https://info.bma.ai/en/actual/eva4/

Building from source

Install Rust
Set the following environment variables and run cargo:

# The variable ARCH_SFX must be set either to "x86_64-musl" or to
# "aarch64-musl". If updates from the official repository and/or cloud manager
# CLI are not required, the variable can be set to any value.
export ARCH_SFX=x86_64-musl
cargo build --release

For OpenSSL v3 FIPS 140, build with "openssl3" feature enabled. In case of any problems with FIPS 140 support in OpenSSL, enable "openssl-no-fips" feature.

The following libraries must be manually downloaded, installed and/or compiled:

svc/controller-enip requires libplctag
svc/controller-trap requires libnetsnmp
svc/controller-w1 requires libowcapi and libow

The "ffi" service (svc/ffi) must be built separately and never as a static binary, as it dynamically loads service libraries in runtime.

The controller-system service (svc/controller-system) must be built separately with a feature to set required mode (to build as EVA ICS service set "service" feature).

The following services are not open-sourced (the source can be provided for mission-critical projects under an additional agreement):

eva-aaa-msad - Active Directory authentication service
eva-zfrepl Zero-failure replication service
eva-kioskman HMI Kiosk manager service
eva-aaa-accounting Event accounting and audit

About the authors

Bohemia Automation / Altertech is a group of companies with 15+ years of experience in the enterprise automation and industrial IoT. Our setups include power plants, factories and urban infrastructure. Largest of them have 1M+ sensors and controlled devices and the bar raises higher and higher every day.

eva4's People

Contributors

Stargazers

Watchers

Forkers

opentinyhouse elasticdotventures curtiseng jkylin julian-brito alexsidou heguangwu

eva4's Issues

excessive timestamps in logs for docker environment

Docker logs maintains timestamps.
Eva logs with timestamps no matter wether it runs in docker or not.
Such behavior result in excessive timestamp information in docker logs, which is not necessary.

Issuing the following command, note the -t swich which turns on timestamp display.
docker logs -t addon_local_eva_ics 2>&1 | less
will result in double log timestamps :

2024-02-23T09:03:00.849643126Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] parsing environment variables
2024-02-23T09:03:00.849701848Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] reading the deployment file /mnt/init/init-99-discovery-service.yml
2024-02-23T09:03:00.849842543Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] parsing template tags
2024-02-23T09:03:00.849975321Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] parsing YAML structure
2024-02-23T09:03:00.850086937Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] extending
2024-02-23T09:03:00.850102950Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] parsing the payload
2024-02-23T09:03:00.850125833Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] analyzing upload
2024-02-23T09:03:00.850131951Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] connecting to /opt/eva4/var/bus.ipc
2024-02-23T09:03:00.851569139Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] local node: local-eva-ics
2024-02-23T09:03:00.851604425Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] testing node .local
2024-02-23T09:03:00.851995906Z [2024-02-23T09:03:00Z WARN  eva_cloud_manager::deploy] starting deployment
2024-02-23T09:03:00.852010650Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] deploying node .local
2024-02-23T09:03:00.852014724Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] deploying items
2024-02-23T09:03:00.852290635Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::core local item created: lmacro:eva.macro.discovery/discovery
2024-02-23T09:03:00.866045984Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] deploying services
2024-02-23T09:03:00.866324836Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svcmgr deploying service eva.controller.py
2024-02-23T09:03:00.876250089Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svcmgr deploying service eva.controller.discovery
2024-02-23T09:03:00.881881268Z [2024-02-23T09:03:00Z INFO  eva_cloud_manager::deploy] waiting services start
2024-02-23T09:03:00.888748036Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svc eva.controller.discovery Logic Manager programmable controller started (eva.controller.discovery)
2024-02-23T09:03:00.888934023Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svc eva.controller.discovery starting cycle cycle
2024-02-23T09:03:00.888951580Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svc eva.controller.discovery running cycle #cycle, interval: 10s
2024-02-23T09:03:00.890436619Z 2024-02-23T10:03:00+01:00 local-eva-ics  ERROR eva::actmgr action 522d4006-1be6-4264-9830-0646431a6426 for lmacro:eva.macro.discovery/discovery failed at launch: Bus client not registered
2024-02-23T09:03:00.890673858Z 2024-02-23T10:03:00+01:00 local-eva-ics  WARN eva::svc eva.controller.discovery cycle cycle error: lmacro/Some(String("timeout"))
2024-02-23T09:03:00.948673055Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svc eva.controller.py mod:__init__ fn:run th:MainThread :: dir: /opt/eva4/runtime/xc/py, pool_size: 50
2024-02-23T09:03:00.948717558Z 2024-02-23T10:03:00+01:00 local-eva-ics  INFO eva::svc eva.controller.py mod:__init__ fn:mark_ready th:MainThread :: Python macros runner started
2024-02-23T09:03:02.884460189Z [2024-02-23T09:03:02Z INFO  eva_cloud_manager] operation completed
2024-02-23T09:03:02.886343798Z Deployment completed
2024-02-23T09:03:39.098084179Z 2024-02-23T10:03:39+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:03:44.288378518Z 2024-02-23T10:03:44+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:03:49.478308465Z 2024-02-23T10:03:49+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:03:54.658975540Z 2024-02-23T10:03:54+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:03:59.849283290Z 2024-02-23T10:03:59+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:04:05.028777079Z 2024-02-23T10:04:05+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out
2024-02-23T09:04:10.219068817Z 2024-02-23T10:04:10+01:00 local-eva-ics  ERROR eva::svc eva.controller.controller1 block pull failed for i1 / 2: Timed out

fix eva-webengine

please, check my pull request: eva-ics/eva-webengine#2

Unknown timezone when using eva console

Steps to reproduce:

(venv) root@local-eva-ics:/# export TZ=Asia/Riyadh && eva
Traceback (most recent call last):
  File "/opt/eva4/venv/bin/eva", line 3, in <module>
    import eva4_shell.shell as shell
  File "/opt/eva4/venv/lib/python3.8/site-packages/eva4_shell/shell.py", line 5, in <module>
    from .sharedobj import common, current_command
  File "/opt/eva4/venv/lib/python3.8/site-packages/eva4_shell/sharedobj.py", line 14, in <module>
    TZ=pytz.timezone(time.tzname[0]))
  File "/opt/eva4/venv/lib/python3.8/site-packages/pytz/__init__.py", line 188, in timezone
    raise UnknownTimeZoneError(zone)
pytz.exceptions.UnknownTimeZoneError: '+03'

Expected result: console working properly.

question

Hello. Thanks for a wonderful product. I haven't used it in a production environment yet. However, I would like to know if there are plans to create an SDK in other languages. For example, dart or golang.

eva4-svc-controller-py do not honor absolute path

Service config:

  - id: eva.controller.py
    params:
      command: venv/bin/eva4-svc-controller-py
      bus:
        path: var/bus.ipc
      config:
        macro_dir: /homeassistant/addons/eva_ics
      user: nobody

Expected result:
controller looks for macros using absolute paths.

Result:
controller appends path to the default one:

  File "/opt/eva4/venv/lib/python3.8/site-packages/eva4_controller_py/__init__.py", line 113, in safe_run_macro
    run_macro(i, args, kwargs, timeout, env)
  File "/opt/eva4/venv/lib/python3.8/site-packages/eva4_controller_py/__init__.py", line 86, in run_macro
    code = compiler.compile(fname)
  File "/opt/eva4/venv/lib/python3.8/site-packages/eva4_controller_py/__init__.py", line 43, in compile
    mtime = os.path.getmtime(fname)
  File "/usr/lib/python3.8/genericpath.py", line 55, in getmtime
    return os.stat(filename).st_mtime
FileNotFoundError: [Errno 2] No such file or directory: '/opt/eva4/runtime//homeassistant/addons/eva_ics/room1.fan_control.py'

pubsub output - not working correctly without reporting interval

At the moment there are two options:

use interval to send data every X seconds.
realtime to send data as they are changed.

Which results in weird behavior for relays and other user-controllable modbus entities.
At startup, mqtt pusher does not send anything because no change is made and respective MQTT entity became unavailable, untill entity state changed (e.g. relay triggered). However, it cannot be changed because it is controlled by user, user cannot control entity because it is unavailable.

Expected behavior:

All entities after startup/autocreation are marked as changed as in fact they are - they created.
MQTT detects those entities are changed and pushes data to the broker.

Some side thoughts.
The output missing a throttling behaviour, which means : it should send data at most the interval seconds. E.g. if data changes too often, without interval the broker will be flooded. But if data changex rarely - they should be sent as soon as they changed.

For example:
FAN RPM: changes every 1 seconds, with interval 30 seconds the data will be sent at most every 30 seconds.
Relay state: the confirmation must be sent as soon as it changes. If relay changes it's state, it is weird to wait 30 seconds for getting confirmation from the mobdus (but we must wait because interval is 30 seconds).

Combining above and summing the FRQ:

All pubsub entities must be reported at startup or in X seconds after startup.
There should be throttling mechanism for spammy sensors, which adopts to entities like relays, which are not spammy and require immediate response to pubsub.