4 ms·

Design obsolescence is absolutely built-in for railway systems (safety related or not). It’s part of the fun of the profession to deal with bizarre voltages tha

by crocal 7y ago

Design obsolescence is absolutely built-in for railway systems (safety related or not). It’s part of the fun of the profession to deal with bizarre voltages that are inherited from the 1930s. For sure it’s not something consumer electronics care for but that’s precisely the point I am making. Actually, it’s one of the required extension to ISO 9002 by IRIS, the quality framework for rail engineers. Components are chosen not only for their function but also for their supply availability in the long run. One of the things we look at is « multisourcing »: how many different folks can provide this stuff. The more the better. Going back to this great idea about hardware diversity (that is absolutely not a general rule in railway): with an architecture requiring 3 different hardwares, you essentially shoot yourself in the foot. Instead of having 3 suppliers for one component, now you need to find at least 6 for 3 components. And the probability to face an obsolescence issue has basically tripled... And for what? It’s proven useless by science... :b And as far as dodging bullets, railway is no better than SCADA. Older tech means older vulnerabilities stay in place, and there are countless people on HN that will tell you it’s /not/ a good thing. I don’t think we dodged, I think we were just lucky. There is a reason why now cybersecurity is making its way inside the last revision of standards.

fit2rule 7y ago
> hardware diversity (that is absolutely not a general rule in railway) I don't know where you're working in the industry, but in my company (THALES) its definitely a thing, and we are absolutely working on diversifying the 3-of-3 and 3-of-5 configurations away from Intel. And maybe we're talking about design obsolescence in different terms, but yeah .. 30-year old CPU's are still being shipped to customers, yo. They WANT it, so.
- 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 ago
    Its 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?

by crocal 7y ago

fit2rule 7y ago

> hardware diversity (that is absolutely not a general rule in railway) I don't know where you're working in the industry, but in my company (THALES) its definitely a thing, and we are absolutely working on diversifying the 3-of-3 and 3-of-5 configurations away from Intel. And maybe we're talking about design obsolescence in different terms, but yeah .. 30-year old CPU's are still being shipped to customers, yo. They WANT it, so.

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 ago
  Its 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?