[SystemSafety] The Mailing List(s)

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>