[SystemSafety] Collected stopgap measures

Jonathan Ostroff jonathan at yorku.ca
Fri Nov 2 17:22:18 CET 2018 

I teach a 4th year course on Software Engineering Requirements. This is a systems safety list but I assume that documenting requirements is important for the production of systems that are safe and fit for purpose. There is a large literature and many textbooks that deal with software requirements but not so many that address requirements engineering for safety critical systems.

To students I recommend:

https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf <https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf>

which is a handbook that presents a set of recommended practices on how to collect, write, validate, and organize requirements (in the aviation domain butI think applicable elsewhere). I would be interested in other available teaching resources if they exist.

The course uses TLA+ and PVS for validating specifications (which is different from verifying that code satisfies specifications). In the course, PVS is used to check that function table specifications are complete and disjoint (in line with earlier work by David Parnas in the nuclear domain).
https://wiki.eecs.yorku.ca/course_archive/2018-19/F/4312/start <https://wiki.eecs.yorku.ca/course_archive/2018-19/F/4312/start>
 
Jonathan Ostroff


> On Nov 2, 2018, at 10:57 AM, John Howard <john.howard at ieee.org> wrote:
> 
> I too am just beginning and would find something like this useful.
> Just for a point of reference. I am currently taking a "Software Systems Engineering" class towards my Masters in Systems Engineering, and here are some notes I captures from our one and only lesson on V&V for Safety Critical Software.
> 
> I'd be interested to know what the experts on this list think of this (how complete is it?).
> 
> Also, does anyone know of good courses that teach this stuff? 
> 
> V&V Methods for Software in Safety Critical Systems
> Static Analysis
> 
> -        Formal methods (Mathematical Proof)
> o   Need specialized notations, and can be very expensive
> o   May be able achieve same level of rigor without such expensive methods
> -        Model Checking
> o   Use a state machine model of the system
> o   Valuable for concurrent systems
> o   Tools today are practical for small to medium systems
> -        Automated static analysis
> o   Tools which analyze source code
> o   Code as a supplement to but not a replacement for code inspections
> o   Can add your own rules and for enforcing coding styles
> o   Valuable for identifying specific security issues
> 
> Reliability Testing
> 
> -        Four validation activities:
> o   Establish the operational profile for the system
> §  Identify classes of system inputs and the probability that these inputs will occur in normal use
> o   Construct test data reflecting this operational profile
> o   Test the system and observe the number of failures and the times of these failures
> o   Compute the reliability after a statistically significant number of failures have been observed
> 
> Security Testing
> 
> -        Experience Based validation testing (against known attacks)
> -        Tiger-teams (a form of experience based testing)
> -        Tool based validation testing (experience is embodied in the tools themselves)
> -        Formal verification
> -        Static analysis can be used to supplement security testing
> 
> Process assurance
> 
> -        Dependability is assured because the processes which ensure dependability are followed throughout software development.
> o   Do we have the right process?
> o   Are we doing the process right?
> -        Generated a lot of documentary evidence
> -        Examples include:
> o   Creation of a hazard monitoring and logging system that traces hazards through analysis, testing, and V&V
> o   Appointment of project safety engineers that have explicit responsibility for the safety of the system
> o   Extensive use of safety reviews
> o   Creation of a safety certification system where safety critical components are formally verified
> 
> o   Detailed Configuration Management
> 
> 
> 
> 
>     
> 
> On Thu, Nov 1, 2018 at 1:37 PM Tim Schürmann <tschuerm at techfak.uni-bielefeld.de <mailto:tschuerm at techfak.uni-bielefeld.de>> wrote:
> From the viewpoint of somebody still in the beginning:
> 
> I wold love to have something like this.
> 
> May it even be just a list of references, papers, "does and don't does"
> or alike..
> 
> Kind regards
> 
> Tim
> 
> 
> On 01.11.2018 16:34, Olwen Morgan wrote:
> >
> > One thing that I sense (maybe wrongly?) from recent traffic is that a
> > goodly few of us use our own favourite techniques to help plug the
> > holes in weak development practices. Cut-down structured and OO
> > methods seem to be a case in point. I'm sure there are others.
> >
> > Might there be some benefit in gathering here the tricks that many of
> > us may have used when faced with inadequate processes. Call me
> > simple-minded (many have called me worse) but I'm wondering if there
> > would be value in what might be called a "Software Process Cookbook"
> > of "Software Process Checklists" for high-integrity developments.
> >
> > True, I'd prefer something direct, technical and possibly rather dry
> > but I'm thinking here about an appealing format. I'm wondering if
> > something like a cookbook or "for Dummies" format would appeal to
> > people who would otherwise never go near the sources that they need to
> > be accessing to help them do the job better.
> >
> >
> > Just a thought,
> >
> > Olwen
> >
> >
> > _______________________________________________
> > The System Safety Mailing List
> > systemsafety at TechFak.Uni-Bielefeld.DE <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
> > Manage your subscription:
> > https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety <https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety>
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety <https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety>
> 
> 
> -- 
> John Howard
> Sr. Systems Engineer
> Robotic Research LLC <https://www.roboticresearch.com/>_______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181102/efb5c700/attachment-0001.html>

More information about the systemsafety mailing list