2 minute read
Comment
from NE_22_11_20
by Hiba Dweib
www.newelectronics.co.uk/forum Your electronics community discussion board
Group Editor: Graham Pitcher Web Editor: Chris Shaw Deputy Web Editor: Laura Hopperton
Advertisement
Contributing Editors:
David Boothroyd, Chris Edwards, Louise Joselyn, Roy Rubenstein Art Editor: Martin Cherry Illustrator: Phil Holmes Key Account Director: Tricia Bodsworth Classified Sales: James Slade Circulation Manager: Chris Jones (circulation@findlay.co.uk) Production Controller: Nicki McKenna Publisher: Peter Ring Executive Director: Ed Tranter
Represented in Japan by:
Shinano International: Kazuhiko Tanaka, Akasaka Kyowa Bldg, 1-6-14 Akasaka, Minato-Ku, Tokyo 107-0052 Tel: +81(0)3 3584 6420
New Electronics: Tel: 01322 221144 Fax: 01322 221188
www.newelectronics.co.uk email: ne@findlay.co.uk
ISSN 0047-9624
New Electronics, incorporating Electronic Equipment News and Electronics News, is published twice monthly by Findlay Media Ltd, Hawley Mill, Hawley Road, Dartford, Kent, DA2 7TJ Copyright 2011 Findlay Media. Annual subscription (22 issues) for readers in the UK is £106, overseas is £161, and airmail is £197.
Origination by CTT, Walthamstow, London E17 6BU Printed in England by Wyndeham Heron Ltd, Heybridge, CM9 4NW
Moving on? If you change jobs or your company moves, please contact circulation@findlay.co.uk to continue receiving your free copy of New Electronics
Not fit for purpose?
Is the software written for safety critical systems not up to scratch?
It is an accepted fact that electronics and, by association, software have per vaded our lives. And we can assume that the vast majority of safety systems today are based on some form of electronic control. So it is a bit worrying to hear an independent safety consultant claim that most critical software has been built ‘using methods that aren’t fit for purpose’.
The consultant is par ticularly scathing regarding the use of C as the de facto programming language. He believes C is weak and, by implication, has no role in safety critical software. In fact, he is not entirely complementary when it comes to MISRA C, the variant used by the auto industry, among others, to bring more stringency to bear.
But his criticisms move beyond C to address the whole approach to the question of safety critical system development. He despairs, for example, at the decline in the use of the formation specification. He also sees weaknesses in the way in which systems are defined; in his opinion, the way boundaries are drawn are defective. When systems are defined, he contends, people forget there will be users and those users will be inside the system.
So we have to ask whether things are as bleak as they appear. The answer has to be no, although the points made are impor tant. In the opinion of the Safety Critical Software Club, ‘there aren’t as many accidents as there used to be, because we can do lots of things to avoid problems’. But the Club admits, despite all this, accidents still happen.
And accidents happen not only because systems are becoming increasingly complex, but also because of the interactions with other systems and with people. Exploring every possibility is out of the question, but it is incumbent upon engineers to use every possible tool available to them and that includes using a language like SPARK, instead of C.
