?

Log in

No account? Create an account
SCADA and MTBH - Whizistic's Lair — LiveJournal [entries|archive|friends|userinfo]
William

[ website | never working right seemingly ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| arstechnica.com the-whiteboard.com userfriendly.org ctrlaltdel-online.com slashdot.org ]

SCADA and MTBH [Jun. 10th, 2006|08:44 am]
William
From a systems design book written in 1995:

Operations can no longer afford the luxury of dedicated stand-alone systems. Hardware and software of the modern SCADA system myst be incorporated into the enterprise-wide, management information systems strategy to maximize the benefits.

Translating from PHB speak: Run your SCADA system over your enterprise network, rather than have an independent out-of-band means of communication.

From a systems design document from BART, written slightly more recently:

The station computer itself is divided into two systems. First is the Non-Vital Station Computer (NVSC). ("Vital" in the context of railroad safety can be interpreted to mean that the function is critical to the safety of the system.) The NVSC is a fast, flexible computer. The hardware is reliable enough to meet performance-driven Mean Time Between Failure (MTBF) and Mean Time Between System Shutdown (MTBSSD) goals but not safety-related Mean Time Between Hazard (MTBH) goals. These goals are defined precisely below. Second is the Vital Station Computer (VSC), which is slower but reliable enough to meet safety-related MTBH goals.

Now, I realize I'm comparing apples to oranges here. The first quote is referring to SCADA controls for power distribution, designed to keep the power flowing, while the second quote is talking about SCADA controls for people-moving and keeping people-movers from becoming airborne or hitting eachother. Clearly the risks involved in a failure of SCADA controls in these two examples, be it via computer virus or lightning strike, are not equivalent. Still, the thought of running what we term as "safety sensitive" systems over your typical enterprise network[1] makes every one of our controllers blood run cold. And yet, that's where things are moving to. Some SCADA salesman: "Yeah, the PLC just has a rj-45 jack on it, plug it in and it'll get a dhcp address..."

I need a bigger cluebat.


[1] Well, maybe your enterprise network can meet a MTBH goal of no hardware faults in 10^9 hours. Mine certainly can't.
linkReply

Comments:
[User Picture]From: jgp
2006-06-10 08:58 pm (UTC)
What do you mean, your network can't meet an uptime of 114,000 years? Disappointing.
(Reply) (Thread)
[User Picture]From: whizistic
2006-06-10 09:37 pm (UTC)
Actually, I can; you can't get hardware faults if the network doesn't exist. :)

Well, the rule actually says no hardware faults which cause a Hazard (i.e. possibility of train derailment or collision), which can be avoided through redundency, but then you get into those more systemic network issues like broadcast storms and routing loops, which apparently don't count. Gotta love the feds and their wording from 1970's relayville.
(Reply) (Parent) (Thread)