begin oe_protect.scr
Post by Benoît CosandeyPost by Mark Kentbegin oe_protect.scr
Post by Benoît CosandeyPost by Mark KentThe problem is that it could've been very real.
I think this is the point. i.e /could/
Post by Mark KentI used to write code
for 8-bit systems, and used short date codes in the 1970s and early
1980s. I had no idea that my kit would still be in use nearly 30 years
later monitoring gas supplies, but it was. I've no idea what might've
happened if it hadn't been replaced, have you? What if there'd been a
major gas leak, but the system hadn't detected it?
1. informatic/microprocessor systems compute dates among other thing
2. Y2K affect informatic/microprocesor system computing dates
3. infomatic/microprocessor supervise other system (gas delivey,
electrical network, nuclear plant...)
4. gas is inflammable/expolsive
deducing that Y2K may help let an explosion of gas is hilarious for
knowledgeable people (hence the farce described by Sinister and Punk)
and fear inducing for Pa and Ma.
1.- Dates have nothing to do with a real time alarming system
Doh! Of course they do - do you have any experience with real-time
alarming systems at all? The timing of alarms is positively critical,
so that when they're introduced into correlation engines, they can be
correlated together in order to give various possible causes, with
probabilities and locations.
Well, we are maybe talking about two different things here.
No, I'm talking about how real systems work, you seem to be making
things up.
Post by Benoît CosandeyWhen you have a system to be supervised (like gas duct, or production
1.- security
2.- operation
These 'layers' do not correspond to any realistic model which could be
used to monitor anything. Monitoring systems have to take account of
the topology of what they're monitoring, and have to take account of the
severity of alarms and their interconnectedness.
Post by Benoît CosandeyAt the security level, you have sensors/detectors that are fail-safe,
meaning that if they fail, you get at least the same alarm as if they
detected a problem.
I'm sorry, but you have such a naive view of how these things work, it's
hard to know where to begin. Basically, all of the above is wrong.
Apart from anything else, the /last/ thing you want sensors to do if
they fail is act as if there is a /different/ problem. Imagine if
you're managing a network with 5,000,000 nodes, and 10% of them begin
sending failure alarms? Your correlation system would be flodded.
Post by Benoît CosandeyTheir alarm start an automated procedure (shuting down the flow, or
shunting it over an alternate path) AND report back the alarm and the
action taken.
If your scenario were correct, then it would be the only thing you could
do. This means that /any/ sensor failure of any kind would result in
supplies being cut off. This would cause an unstable system. This is a
dumb design.
Post by Benoît CosandeyThen it enters the operation layer
Ahh, no...
Post by Benoît CosandeyThere it becomes analysed and correlated to understand the probable
cause and how to avoid those in the future or optimise the system or
even start a bigger response like what happens when a domino effect is
taking place.
No no no no no no no no..... correlation is there because when a
failure occurs on any network, it causes impacts across significant
parts of the network, not just one. The correlation provides probable
causes so that problems can be localised and appropriate action taken.
The time and date when alarms occur is fundamental in that it determines
how the collection and correlation engines process the alarms. Imagine
if you start feeding alarms from your monitoring node which are 50 years
or 100 years out of date - any sensibly designed mediation device would
discard them as junk data. /this/ is why the date and time are so
important...
Post by Benoît CosandeyAt the secutirty level, we care about life (avoid/limit accident to
avoid life losses), while at the operational level care is given to
economics (avoid accident to avoid financial losses and running a more
efficient system).
I still say that at the security level dates are of no big meaning.
while they are at the operational level.
That's because you've not got your head around networks and network
monitoring - you're quite wrongly imagining that any event will only
impact one place, location, node or device - this is wrong - networks
are characterised by interconnectedness, which monitoring systems have
to be able to model to a reasonable degree in order to provide sensible
direction to operations centres and maintenance staff, rather than just
lighting up boards like christmas trees, as you'd expect if you watch
too many hollywood movies.
Post by Benoît CosandeyThe point was that although action had to be taken to correct Y2K, the
amplitude of it was to much hyped.
A chocolate factory would have been equally affected (at risk at the
operational level), but ironically the news did only mention gas/nuclear
plant. This kind of distortion of information is aimed to "normal"
people to help the sales of the media, but did it contribute to
efficiently take care of the problem at hand ?
Post by Mark KentPost by Benoît Cosandey2.- Supervising gas supply with a far overaged (around 30 years old)
electronic/informatic system is a kisk with or without Y2K
Wow - you missed the whole Y2K thing, didn't you? I /still/ have
fully functioning computers designed well before then.
I was right in, thanks. It was really a dilbertian time.
Post by Mark KentUsing old hardware, once it's gone through it's initial bath-curve
point, is the right thing to do, /until/ either it starts to become
unreliable (you won't know when that'll be until it happens), or there
is a much more cost effective replacement possible, which, /including/
the cost of writing off the existing system early and buying the new one
still shows a saving. As I'm sure you can see, this almost never
happens.
Sure, not being on the edge is always a safe position. Still 30 years
old electronic hardware is a risk in itself, greater than any Y2K thing.
No, it's not. You didn't read what I said, did you? Once you're past
the bath-curve problem, there is no reason to change anything /until/ it
starts to fail.
Post by Benoît CosandeyUsually, the write-off period is around 5 years,
Rather than making up numbers, why don't you use some real ones? Much
of the worlds telcos are using kit over 20 years old even now, some as
much as 30 years old. This is the /same/ kit which is used for
monitoring other systems - where do you think the leased lines come
from?
The London tube system is over 100 years old in parts...
Post by Benoît Cosandeymaybe 10 for
military/security kind of material. 30 is more for building or
infrastructure (pipes...)
No, pipes can be 50 - 100 or more. You need to find /real/ numbers,
don't make them up.
Post by Benoît CosandeyBut I agree, that management are rarely early in exchanging
system/hardware. Still at the security level, those
sensors/detectors/state machines are checked an a regular basis and
replaced more often than every 30 years.
Don't make things up, please. Get some real evidence & use it. Let me
tell you again, much of the world's telcos are still using equipment of
the order of 30 years old. That /includes/ management and alarming
functions.
Post by Benoît CosandeyPost by Mark KentPost by Benoît Cosandey3.- Chances that a gas leak / overpressure happens at the same time a
supervising system goes down are thin, and this is why supervising
system are themselves supervised and under alarm
The chances of a problem at any time are thin, alarm systems are not
there for that reason at all. Alarm systems are there before there is a
finite probability of a problem at any time, which means that they do
occur, and have to be tracked down.
Of course. I was speaking of the probability of two events at the same
time (Y2k indeuced and gas leak). Still there but thiner.
Common mode failure is not uncommon, just statistically less likely.
Post by Benoît CosandeyPost by Mark KentMost problems are caused by 'JCB' events, ie., street work damaging
underground facilities. They are common. If they weren't common, and
problems weren't common, alarm systems would not be required, would
they?
Couldn't agree more.
Post by Mark KentI've never heard of anyone putting a management system on a management
system, but you rather missed the point, didn't you?
This has more to do with my english, sorry. I was referring to
"fail-safe" system which are very common at the security level.
How can something 'fail-safe' if it's operating out of its original
design parameters? You've no idea what it'll do - the state machine is
no longer in states it was designed for - it could do anything.
Do you think disconnecting power to something is "safe" if there's no
problem - what if you're powering a hospital, say? How safe is it
then?
Post by Benoît CosandeyPost by Mark KentIf your system is
based on code written 23 years earlier (say, 1977), with several
thousand instances of devices with that code in around the country, how
will /knowing/ that the alarm system has failed help you[1]? It won't!
The /only/ thing you could do would be to disconnect the whole supply
system for safety reasons - this in itself would be pretty disastrous,
which is why the only /sensible/ thing to do is a Y2K project to remove
all the offending parts, so you never get to the point where you have to
make that decision.
You are right. This is exactly the operational problem caused by Y2K.
If you understand this, why are you arguing that it wasn't necessary?
Post by Benoît CosandeyPost by Mark Kentnote[1]: as you're heading into state machine conditions which were
never intended, you do not even know how the system will behave - it
might indicate faults where there are none, it might flood the
correlator with alarms, it might become unresponsive for extended
periods, then light up all alarms for a while - you've just /no/ idea
what would happen. This is why the Y2K thing was risky - all our state
machines could've been pushed into states they were not designed to be
in; results would be unpredictable. Imagine if a missile launch system
were in a similar position, say? Or your ambulance control system? Or
perhaps your telephone network? The whole point of Y2K was to ensure
that people realised and understood the risks well enough to take the
required action to make sure it wasn't a problem.
Well the people you mention are not informed by the press at large. They
were informed by more "internal" ways. Again no need to submerge Pa and
Ma with apocalypse prediction to launch effecient counter-measure.
Haha! How do you think people in your company, or in other companies,
get their information? (or whatever organisation you're in). They do
it the same way as everyone else - they watch the television, read the
newspapers, listen to the radio. They're not magically connected to
better quality information than your or I. Your senior managers,
whoever they might be, are only as well informed as you are. Also,
because they're senior, they might not be up to speed technically
either, or might have no knowledge or experience of the affected part of
their company or operation, so they're dependent on more junior people
informing them, or external organisations doing so.
Post by Benoît CosandeyWhy always choose missile launch or amublance control, why not billing
system (which were one of the most affected system), chocolate factory
or gardening tools factory. Maybe because "people" would then have
understood that that was a purely technical problem to be solved by
technicians, and that if those technicians would be doing the kind of
job they do every day, they (the public) would not be otherwise affected.
Because the chocolate factory and billing engine don't matter, of course,
just as you seem to realise - I don't care whether the choccy factory has
fixed its y2k problems, but I /do/ care that the hospitals, ambulances,
telcos, power suppliers, traffic managers, airline traffic controllers,
naval traffic managers, car manufacturers, missile suppliers have fixed
them, because if they don't, there is a *significant risk to life*.
It was not a 'purely technical problem', indeed, there are no 'purely
technical problems', except those scientists consider in their labs.
Others have perhaps minor or major business impact, some have minor or
major impacts on society, possibly so far as causing deaths, possibly
widespread deaths.
I'm very keen that the high risk items are given a high priority. That
can require significant publicity.
Post by Benoît CosandeyPost by Mark KentPost by Benoît CosandeyYou seems to think that the "population" needs to be more informed about
risks of all sorts.
No, I didn't say that. I said that the population at large is very poor
at assessing risks, something you've proven in your posting above, in
that not only can you not comprehend the risk, you appear unsure even
about how the kind of system works you're trying to analyse.
I just saved 100$ in psychotheraphy thanks to you.
The population at large may be poor at assessing risks, so that's why
some would like to assess those for them. I don't particularly like the
kind of society based on such ground.
You seem unable to comprehend the difference between a y2k problem at a
chocolate factory and a y2k problem at a missile factory. I don't think
I've saved you anything.
Post by Benoît CosandeyPost by Mark KentPost by Benoît CosandeyI would say that this zero risk society some are
wishing so much is not attracting me the least bit. And that the press
(radio/tv included), good or bad, may be the only way to inform,
certainly not the best way to educate.
Your last sentence doesn't seem to make sense.
I'll give you that. My poor english. I won't be able to express correcly
what's in my head, so I'll stop there.
Ben
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
While there's life, there's hope.
-- Publius Terentius Afer (Terence)