| Antivirus |
widely used, easily updated |
complicated and often imposible, network detection and prevention solutions mostly |
Similarly complicated, lots of technology fragmentation (different RTOSs, embedded frameworks and communication paradigms), network detection and prevention solutions exist |
complicated and complex due to the technology nature, very few existing solutions (e.g. RIS), network monitoring and prevention isn't enough due to safety implications |
| Life cycle |
3-5 years |
10-20 years |
5-10 years |
10+ years |
| Awareness |
Decent |
Poor |
Poor |
None |
| Patch management |
Often |
Rare, requires approval from plant manufacturers |
Rare, often requires permission (and/or action) from end-user |
Very rare, production implications, complex set ups |
| Change Management |
Regular and scheduled |
Rare |
Rare |
Very rare, often specialized technitians |
| Evaluation of log files |
Established practice |
Unusual practice |
Unusual practice |
Non-established practice |
| Time dependency |
Delays Accepted |
Critical |
Some delays accepted (depends of domain of application, e.g. IIoT might be more sensitive) |
Critical, both inter and intra robot communications |
| Availability |
Not always available, failures accepted |
24*7 |
Some failures accepted (again, domain specific) |
24*7 available |
| Integrity |
Failures accepted |
Critical |
Some failures accepted (again, domain specific) |
Critical |
| Confidentiality |
Critical |
Relevant |
Important |
Important |
| Safety |
Not relevant (does not apply generally) |
Relevant |
Not relevant (though depends of domain of application, but IoT systems are not known for their safety concerns) |
Critical, autonomous systems may easily compromise safety if not operating as expected |
| Security tests |
Widespread |
Rare and problematic (infrastructure restrictions, etc.) |
Rare |
Mostly not present (first services of this kind for robotics are starting to appear) |
| Testing environment |
Available |
Rarely available |
Rarely available |
Rare and difficult to reproduce |
| Determinism requirements (refer to for definitions) |
Non-real-time. Responses must be consistent. High throughput is demanded. High delay and jitter may be acceptable. Less critical emergency interaction. Tightly restricted access control can be implemented to the degree necessary for security |
Hard real-time. Response is time-critical. Modest throughput is acceptable. High delay and/or jitter is not acceptable. Response to human and other emergency interaction is critical. Access to ICS should be strictly controlled, but should not hamper or interfere with human-machine interaction |
Often non-real-time, though some environment will require soft or firm real-time |
Hard real-time requirements for safety critical applications and firm/soft real-time for other tasks |
