EVA ICS version 3 has become the most successful industrial IoT product of our company. It already has dozens of setups we support directly and I hope even more setups we don’t.
But the version 3 has a problem: because of the rapid numbers of customers and features growth, it’s internal architecture was changed several times almost from scratch, lots of stuff already became obsolete and too complicated for beginners.
Here are the plans for the EVA ICS codename “nextgen” (next generation):
Synchronization protocols
The cloud synchronization protocols are tested, work fine and should be kept as-is (or almost as-is) but there definitely should be a way to notify nodes about new / deleted cloud items without waiting for a full reload. This will allow to have completely real-time setups, even where items are added/removed frequently.
So, yes, sync protocols and sync architecture will be the same: http/websocket for the p2p connections and MQTT (with the same topic layout) for large setups.
Nodes
We had lots of discussions, should be or shouldn’t be node functionality merged into a single process or there should be several daemons (“controllers”). The split functionality makes a node much reliable but the components need to be inter-connected, which brings additional system overhead. But as we’ve found, customers in large, mission-critical setups, prefer to have nodes with a single component functionality, the reliability becomes obsolete.
So, yes, node functionality will be merged into a single component. No more “controllers” just one install = one node.
Scalability
Current EVA ICS core allows setups to be scaled up to dozens thousands of items and to hundreds of nodes. Our goal is to let EVA “nextgen” work with millions of items and thousands of nodes on regular low-power industrial computers.
Remote macros
Currently it’s tricky running macros on the remote nodes. Merging components will allow any local macro to execute a remote one as easy as locals.
Items
Is there a way to merge “units”, “sensors” and “lvars” into a single type of items, “objects” or “tags” (hello, EnIP)? All these items have very different functionality and logic so it’s pretty hard to merge everything but keep it as simple as now. This is the absolutely undecided topic and we’re working on it, testing different approaches.
Drivers
Splitting driver functionality and logic into “PHIs” and “LPIs” allowed us to quickly implement driver support in EVA ICS core for different tasks, but according to our experience its flexibility is too complicated to understand, customers prefer “basic” logic for drivers for most cases, customers call “PHIs” as “drivers” and have no idea what LPIs are for.
So, this architecture will be kept but renamed. PHIs will become “drivers”, while LPIs will become “driver logic”. But of course, EVA “nextgen” will be compatible with all existing PHIs.
Additionally, PHI modules have very complicated “headers” now. We are definitely going to simplify that in some way.
Buses
Currently EVA ICS has 2 buses built-in: 1-Wire and Modbus. The core virtual buses are required because the hardware buses of that types usually require strict port / resource locking. But the buses are not required in all setups.
So, we’ve decided to make buses optional and allow customers to install them separately.
Plugins
Currently EVA ICS has lots of plugin and extension types (about 6). Despite of number, all these types have different approach and features, so we are going to keep almost all of them, except LM PLC extensions – we are going to move their features into core plugins.
To Rust or not to Rust
There’s a long-term idea rewriting EVA ICS core in Rust. But according to our tests, it doesn’t bring any performance to data transfer, while the core should still have Python interpreter included to allow setups being quickly extended with Python macros/scripts and drivers. However, Rust version could bring memory consumption bonuses, so this question is still open.
API
Direct HTTP and RESTful APIs are becoming obsolete, starting from EVA ICS 3.3.2. We’ve found RESTful to be unpopular with customers, as majority work with EVA ICS API either via IaC deployment, Python API client library or via EVA JS Framework. Also, RESTful API calls are useless, when non-HTTP transfer methods are used. Supporting different API methods brings additional development overhead and bugs, so, definitely:
– EVA “nextgen” will have JSON RPC API only
– There will be “v2” API with more categorized and parameter-optimized functions.
– As “v1” JSON RPC API is used in lots of existing setups, it will be supported as well
– WebSocket subscriptions and MQTT synchronization API will be optimized and opened to public.
Release cycle
As EVA ICS has nearly-perfect backward compatibility, previous versions become obsolete as soon as the new one is released. Patches to “stable” branch are irregular, many customers already prefer “pre-release” versions, build testing is becoming almost completely automatic. There are less and less reasons keeping “stable” and “development” branches and we are going to switch to “stable” and “unstable” builds model. So there will be no EVA “nextgen” versions, no branches, just builds, like most of modern software already have.