Here are some of the Dependability red flags (part 2 of 2):
- Insufficient consideration of system reset approach
System resets might not ensure a safe state during reboots that occur when the system is already in operation, resulting in unsafe transient actuator commands.
- Neither run-time fault instrumentation nor error logs
There is no run-time instrumentation to record anomalous operating conditions, nor are there error logs to record events such as software crashes. This makes it difficult to diagnose problems in devices returned from customers.
- No software update plan
There is no plan for distributing patches or software updates, especially for systems which do not have continuous Internet access. This can be an especially significant problem if the security strategy ends up requiring regular patch deployment. Updating software may require technician visits, equipment replacement, or other expensive and inconvenient measures.
- No IP protection plan
There is no plan to protect the intellectual property of the product from code extraction, reverse engineering, or hardware/software cloning. (Protection strategies can be legal as well as technical.) As a result, competitors may find it excessively easy to successfully extract and sell products with exact software images or extracted proprietary software technology.