[SystemSafety] The Mailing List(s)
peter.sheppard at uk.transport.bombardier.com
peter.sheppard at uk.transport.bombardier.com
Wed Oct 24 12:00:12 CEST 2012
So, the original poll request stated:
"To this end, we have set up a doodle poll that allows current subscribers
to record their vote for the transfer of the list to one of the above
options: Bielefeld, the Safety Critical Systems Club, and the
Professional Bodies. "
And
"However, we are happy to facilitate a transfer according to the wishes of
the majority. No members details will be transferred without their
approval."
In my very simple engineering view, the poll was for the "MAJORITY" to
select "ONE OPTION". This was the SCSC, so why is a "partnership" between
SCSC and Bielefeld now being considered?
Regards
Peter
Peter Sheppard
Senior Safety Engineer and Validator
Mobile: +44 7920 247931
Please consider the environment before you print / Merci de penser à
l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor
Sie drucken
Bombardier Transportation UK Ltd
Registered Office: Litchurch Lane, Derby, DE24 8AD, England
TEL +44 1332 344666, FAX +44 1332 266271
Registered in England
Registration No. 2235994
Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de>
Sent by: systemsafety-bounces at techfak.uni-bielefeld.de
24/10/2012 10:44
To
systemsafety at techfak.uni-bielefeld.de
cc
Subject
Re: [SystemSafety] The Mailing List(s)
Kevin, Paul,
yes, I only sent my comment on the Australian conference to the Bielefeld
List. That is the only
list which I am currently sure works as intended by the list maintainers.
Tim communicated the results of the poll to myself, Tom Anderson, Brian
Jepson who maintains the
SCSC on-line presence, and Zoe Squires of the IET.
Apparently he got about a quarter of the membership voting and the results
were
> 100 in favour of the SCSC
> 88 in favour of (including those already transferred to) Bielefeld
> 4 for Professional Body (IET/BCS)
> 1 who wishes no further involvement in any list
He suggested that SCSC and Bielefeld could "consult" on how a "joint
option" could be pursued. We
already did that two months ago, of course. He didn't say anything about
York providing some sort of
continuing service.
To my mind, a "choice" between SCSC and Bielefeld is relevant only in
terms of whom you trust to run
a SW service. The technical details as discussed can obscure the actual
maintainer. I think there is
a feasible plan on the table which will get slowly but surely executed.
See the next paragraph but
one, and following.
The option of IET/BCS versus SCSC/Bielefeld was a viable choice. It would
be great if the IET
professional society would again decide to support a community which it
decided a couple of years
ago to dump. It is indeed reconsidering, thanks in no small part to the
efforts of the new Convenor
of the IEC Maintenance Team for 61508 Part 3, Audrey Canning. As also the
IET Information Technology
Policy Panel, which includes three primarily safety people including the
chair. And Carl Sandom,
supported by Margaret Fanagan and Zoe Squires, who puts on the IET System
Safety Conference each
year. And John McDermid is active at the BCS. But I also think the
professional societies could well
ask themselves why 188 people to 4 don't trust them to run a mailing list.
So, the planning. We are thinking of registering a new domain name for use
by the list and its
archives. Bielefeld is in process of installing and maintaining archiving
SW. We have such archiving
SW, and we have a version which looks good. But it requires a few hours of
time to install it
properly on an open server according to the Bielefeld TechFak standards
and at the moment they are
up to their ears in work, as am I.
When we are sure how it all runs and what the level of effort is, we will
likely register and switch
to the new domain name and link the old list address to the new name. At
that point it will not
matter technically where the list and its archives are hosted: it is just
an entry in a table at the
nameservice provider to which the list administrator, whether at Bielefeld
or SCSC Newcastle or York
or Timbuctoo, has direct access.
The Bielefeld list includes quite a few people who were not on the York
list, and indeed are not
involved with the British safety scene in any way.
Apropos the IET System Safety Conference, I hope the videos and slides
will soon be available on
iet-tv. In contrast to the SCSC, it may well be that access will be
restricted. I would find that a
great shame. In particular because potential viewers will miss my
appalling flute playing at the
beginning as IET technicians were fixing their IT (which apparently goes
to sleep when displaying
PDF slides. Or maybe just my slides. Which may or may not be a sign of
implicit good taste on its
part) and also the splendid coda by the magnificent Mr. Lorne MacDougall
in full regalia who
completed my talk with a rendering of Gordon Duncan's splendid piece
Pressed for Time. The IET could
put that bit on YouTube.
My slides will be up on my WWW site soon.
I shall also have a longish piece about on-demand versus continuous system
functions on the blog. I
had intended it for this morning, but was waylaid. It turns out that some
eminent system engineers,
including Dave Parnas, Martyn Thomas and John McDermid, think the
distinction is spurious. Whereas
almost all mechanical and electrical engineers I have met, as well as
myself, think it fundamental.
How can that be? Well, the digital logic with which one implements either
type of function is
formally very similar. You need to poll some kind of a sensor for either,
just at different rates,
and react differentially to the sensor values that are returned. But not
all systems follow digital
logic. Indeed, most systems are not digital. Most systems are straight
cause-and-effect. When the
sun shines on your photovoltaic panels, you get electricity coming out.
There is no sensor telling
the system that the sun is shining. When a mouse runs past the sleeping
rattlesnake, the rattlesnake
just reacts and the mouse is gone. It's not as if the rattlesnake is
continuously waking up to see
if a mouse is running past. I think it inadvisable to conflate a system
and its functions with the
means of its implementation.
PBL
--
Prof. Peter Bernard Ladkin, Faculty of Technology, University of
Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
_______________________________________________________________________________________________________________
This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is in
use and will browse through incoming emails.
Thank you.
_________________________________________________________________________________________________________________
Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par
les présentes, avisée qu?il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance,
veuillez nous en aviser et détruire ce message. Veuillez prendre note
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la
sécurité de nos systèmes d'information et qu'elle furètera les courriels
entrants.
Merci.
_________________________________________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20121024/8923ec06/attachment.htm>
More information about the systemsafety
mailing list