3 ms·
You can design your platform in a number of ways to be relatively independant of the underlying CPU model, thereby mitigating the risk of supplier lock-in. All
by crocal 7y ago
You can design your platform in a number of ways to be relatively independant of the underlying CPU model, thereby mitigating the risk of supplier lock-in. All suppliers will try to find a way to achieve such target.
It’s a different thing than saying you need hardware diversity in a majority vote system to achieve better safety. That is demonstrably false. For example, Siemens VCP is /proven/ to be safe and it does not even use a majority vote (see my previous comment for a reference to the VCP)
I prefer not to involve my employers on HN. What I write here is my opinion only.
As for your last remark, let’s be careful in assuming what customers want. The fact that they have to live with obsolete stuff does not necessarily mean they are super happy about it.
- fit2rule 7y agoIts not about the software being independent of the architecture. Its about using diverse hardware platforms to avoid the situation where an un-detected, hardware-level bug affects the voting ability of all participants. We've seen, time and time again, so-called dependable platforms weaken over the years as more and more issues are uncovered. Diverse voting node architecture requirements are designed to prevent hardware bugs from crashing trains, not software bugs. >Siemens VCP /proven/ .. and yet, it still crashed trains. >What customers want Its not obsolete if a customer wants it. Customers want older CPU platforms because the tooling and industry required to support them in the field is long-entrenched, and costs of upgrading to "newer, sexier CPU's", not really worth it if the lesser platforms are capable of doing the job...
- crocal 7y ago> .. and yet, it still crashed trains. Do you have evidence for that claim?