"A Methodological Framework for Software Safety in Safety Critical Computer Systems"

The Journal of Computer Science is frequently overlooked in the Embedded Space for the solutions to many problems, for example the September issue covered topics as diverse as, Speed Control of Switched Reluctance Motor Using New Hybrid Particle Swarm Optimization for the hardware types and among us, and Fuzzy Cost Enabled Cluster Based Multipath Routing Algorithm for Mobile Ad-Hoc Networks for those putting together the latest sensor net.

Of particularly interest to me is A Methodological Framework for Software Safety in Safety Critical Computer Systems [PDF] by P. V. Srinivas Acharyulu and P. Seetharamaiah. These authors have put together one of the best introductions to issues related to the safety of systems controlled by software, from defining the terms to building a model system out of a real model train set to demonstrate the techniques described.

Abstract

"Software safety must deal with the principles of safety management, safety engineering and software engineering for developing safety-critical computer systems, with the target of making the system safe, risk-free and fail-safe in addition to provide a clarified differentaition for assessing and evaluating the risk, with the principles of software risk management. Problem statement: Prevailing software quality models, standards were not subsisting in adequately addressing the software safety issues for real-time safety-critical embedded systems. At present no standard framework does exist addressing the safety management and safety engineering priniciples for the development of software safety in safety-critical computer systems. Approach: In this study we propose a methodological framework involving safety management practices, safety engineering practices and software development life cycle phases for the development of software safety. In this framework we make use of the safety management practices such as planning, defining priniciples, fixing responsibilities, creteria and targets, risk assessment, design for safety, formulating safety requirements and integrating skills and techniques to address safety issues early with a vision for assurance and so on. In this framework we have also analysed integration of applicability of generic industrial heirarchy and software development heirarchy, with derived cyclical review involving safety professionals generating a nodal point for software safety. Results: This framework is applied to safety-critical software based laboratory prototype Railroad Crossing Control System (RCCS) with a limited complexity. The results have shown that all critical operations were safe and risk free. Conclusion: The development of software based on the proposed framework for RCCS have shown a clarified and improved safety-critical operations of the overall system peformance."

Journal of Computer Science
DOI: 10.3844/jcssp.2012.1564.1575
Volume 8, Issue 9
Pages 1564-1575

Do keep in mind it is an introduction, a real Rail Road Crossing Control System (RCCS) would be made from two or more systems running parallel, using different processors, different hardware developed by different teams in different languages such C and ADA. The real fun part is developing a system that must run for a few decades and not the eighteen month life span for many components today.

ASQ Youngstown-Warren Section offering Certified Software Quality Engineer class this fall

For the first time the Youngstown-Warren Section (0805) of the American Society for Quality will be the holding Certified Software Quality Engineer training this fall. If you are interested, please contact Marie Dabelko [mdabelko (AT) kent.edu] at Kent State Trumbull. The class is being taught by Nick Hatzis.

For many years Robin Dudash has been holding CSQE classes in the Pittsburgh Region. Robin also has the class available on-line. Give her CSQE Practice Exam a try and see how well you do.

Requirements Creep

In my last blog entry I mentioned how stressful things can get when we are not given good, or any, requirements for a project, beyond the ship date.  Right after I posted that, I happened to see a message on the IEEE P730 Working Group on Software Quality Assurance Standards email list, by Robin Goldsmith of Go Pro Management, that I thought was worth posting here.  With Robin's permission here is what he wrote:

       "A major cause of creep, quality problems, and overruns comes from the common failure to recognize that what most people call "requirements" (i.e., specifications) actually are a form of high-level design.  The word "specification" is  a synonym for design.  Requirements specifications are human-defined attributes of a product, system, or software which is a presumed way how to satisfy the REAL, business requirements deliverable whats that provide value when met.  The product and its specifications provide value if and only if they satisfy the REAL, business requirements.


       Creep mainly occurs when the product/specifications fail to satisfy the REAL, business requirements, usually because the REAL business requirements have not been defined adequately, which in turn is mainly due to people thinking the product specifications are the requirements.


       The difference often is easier to see in an acquisition situation.  Most formal and informal Requests for Proposals (RFPs) specify the requirements of a product, system, or software the buyer thinks they need.  When the seller sells them such a product, the buyer--not the seller--is on the hook if the product fails to provide expected value.  In contrast, appropriate acquisition involves the seller proposing a product, system, or software to satisfy the buyer's described REAL business requirements.  Then the legal burden is on the seller if the proposed product fails to provide expected value.


       In addition to putting the burden of legal responsibility on the seller, there's a software engineering advantage of requesting the seller to propose a product that meets the buyer's REAL business requirements.  This gives the buyer the opportunity to take advantage of the seller's usually far greater knowledge of the subject area their product addresses, rather than having the less-informed buyer specify the product requirements.


       Well-formed formal and informal contracts and acquirer-supplier agreements  more reliably lead to success because they identify both high-level and detailed REAL business requirements, which usually include various constraints on how those requirements may be met.


       In effective product acquisitions, the seller does include a requirements specification in their proposal; and when the proposal is accepted by the buyer, the seller's entire proposal including any requirements specifications becomes part of the contract the seller is legally bound to deliver--by providing a product that conforms to the contracted requirements specifications.


       Of course, often the seller is engaged to develop a requirements specification as part of the contracted work.  Effective acquisitions then involve a separate subsequent proposal for providing a product that conforms to the requirements specification.  Especially for government acquisitions, the seller producing the requirements specification may be precluded from also proposing a product to meet the specifications they've defined."

Robin is the author of the book, Discovering REAL Business Requirements for Software Project Success; ISBN: 978-1580537704, which I've just added to my reading list.





It requires diligence from all of us to keep the Creeping Feature Creature at bay...

I'm Scared

This week I spent a couple of days at regional seminars. At the Texas Instruments Technology Days 2010 in Cleveland, the thing I found most interesting is TI's new Analog Mirror. A single, large, pixel of their already popular DLP technology. Must be something cool we can do with this mirror? Dynamic Signs maybe?

The other seminar this week was sponsored by Atmel, to drum up design wins for their AVR32 family of parts, here in the Pittsburgh market region.

Most of the seminar was showing how to use AVR32 Studio that is based on Eclipse. Alas I probably won't use these parts because the seven year old machine supplied by the IT department would never handle such a large application. Just a fresh reboot of the machine already has 230M+ of the 512Meg of memory used with cooperate bloatware mandated by IT (Makes their jobs easier).

What is relevant to us here today is a comment that the instructor made, paraphrased:

We had to switch to Eclipse because all of the people coming to the Embedded World from the Microsoft World did not know how to write their programs without such a tool.

I find that scary. We'll end up with large, and potentially unsafe, expensive products, because Management assumes any programmer that can write a business application or web app. can design a safe embedded system if they only have the right tool.

Something else I find scary is the article Think it - Draw it - Build it by Mark Saunders, at Embedded.com.

Mark introduces us to the new Cypress Semiconductor PSoC Creator embedded design tool, for Cypress's new PSoC 3 and PSoC 5 programmable system-on-chip architectures. The PSoC 5 parts are something I want to investigate for use in a board test system I'm designing. You don't know what the board under test may need in a test system so a configurable system is the way to go.

However I find the marketing of this product family to be scary:

...You will not need to know the CPU architecture we're using, or how the analog comparator or digital timer components are implemented...

...[PSoC Creator] abstracts away the hardware so you do not need to be an expert on the device you are using or the inner workings of peripherals you program it with...

For the comparator is any overdrive required, how much? Is there any hysteresis to prevent oscillation? What happens when the counter rolls over, does it do The Right Thing? Hopefully some quality time spent with a quality data sheet (sadly far to many data sheets lack any quality) would answers these questions. Would the people using Eclipse from the Microsoft world even know to ask such questions?

Now are you starting to see why I'm scared? I fear that we are heading down the path of Think it - Draw it - Build it - Ship it - So we get paid for it - Doesn't mater if it works right.

How scared are you about the quality of our future Embedded Systems?

"I Code to Spec"

JustFred said something in the thread about how to deal with handling names, that I found to be all to depressing because it is true far to often:

I code to spec. The product and marketing departments write the spec (what little there is); the QA department amends the spec with overly specific test cases. I suggest that the spec is incomplete and won't handle...but I'm told, just code it to spec. I recommend changed, but we don't have time for edge cases. I point out potential problems, but we're unlikely to get any of those. I warn of potential compatibility problems but we don't care. Are you just trying to be difficult? If there's a problem QA will catch it. The project is overdue already, and by the way here are some new requirements that need to make it in, and we can't change the release date because we already promised the stockholders. Why is your code so complicated, my twelve-year-old kid could write this.

It's not my fault. I code to spec.

-- http://slashdot.org/comments.pl?sid=1690138&cid=32609504.

What happens when developers are held liable for their code? Do we become Management's scapegoat for problems that they would not let us fix?

On a personal note, yesterday I received my re-certification papers from the American Society for Quality (ASQ). I am now officially certified for three more years as a Certified Software Quality Engineer (CSQE).