Course outline

This half-module provides an introduction to the processes and problems of building complex software for use in aerospace applications. Topics covered include:

Lectures

Lectures are on Mondays 2:10pm-4pm; labs are on Thursdays at 9:00 in RC-G12 (Lewin lab in the Computer Science department).

Important: there are no labs in the first few weeks.

The reading weeks are 7 and 12, although last quiz is on Thursday of week 12.

Due to weather conditions, there will be no quiz on Thursday of week 10.

Assessment (each part 20%)

Quizzes are held under exam conditions with me and demonstrators invigilating.

Preparation: last years com421 exam papers + three sample questions and a tutorial sheet. Tutorial sheet and its solution are available.

Tutorials in weeks 6 and 9: FlightGear.

Lecture slides

These will be made available before each lecture.
Week 1 (since it's a ppt, it may look ugly), but it is also available as pdf which should look ok.
Weeks 2 and 3, as ppt or pdf .
The first hour of week 4 and the the second hour. The reference to p.127 of SRI report on slide 4 of part 1 refers to footnote 19.
Week 5-control.
Week 6 -end of control.
Week 8: part 1, part 2.
Week 9, the integration testing part and the rest.
Week 10.
Week 11.
Java code for the flightgear lab session/tutorial is available.

The revised text of the assignment (20%) is here, the original (mentioning "response to buttons pressed slowly") is here for reference.

Background reading

Although my lecture slides will provide most of the relevant material, the following books/papers are recommended:
TopicReference
Introduction to safety, hazard analysis, human factors.

This is the course textbook.

"Safeware system safety and computers", N. Leveson, Addison-Wesley, 1995.

Available in our library.

An example I use to illustrate hazard analysis A320 accident in Warsaw and an example of Why-Because analysis.

Another useful example is The American Airlines B757 Accident in Cali.

Reference information Reading accident reports the first time may feel like learning a foreign language - a pile of unknown terms without which everything is incomprehensible. For this reason, I collected together references to help you understand what it written in those reports. You can use Air traffic publications. Something to keep in mind: the same abbreviation could be used to mean different things, depending on the context. Thus, if you think you found the term you are after, check the context to make sure they agree.
TCAS requirements and specification The requirements and a specification of the TCAS collision avoidance system are available here. In relation to what I've said in the lecture, page 33 of the PDF of this document describes what TCAS should be doing and page 46 describes what it should not. You can enter these pages numbers into the page number of your PDF browser to jump to them; they correspond to pages 22 and 35 of the document, respectively.
IEC61508 An idea of the standard is introduced at the IEC pages here, you may prefer follow the link to `functional safety and IEC 61508' from that page.
Statecharts The STATEMATE Semantics of Statecharts" David Harel, A. Naamad, ACM TOSEM, 5(4), 293-333 - 1996. You can find it on Google.
SpecTRM-RL Please keep in mind that the following references on the language may describe a different (out-of-date) version of it. Use my lecture slides.
  • "Designing Specification Languages for Process Control Systems: Lessons Learned and Steps to the Future", by Nancy G. Leveson, Mats Heimdahl, and Jon Damon Reese. Presented at SIGSOFT FOSE '99 (Foundations of Software Engineering), Toulouse, September 1999.
  • The paper I refer to as [Lev00] in lecture slides is:
    "Completeness in Formal Specification Language Design for Process Control Systems", Nancy G. Leveson. To appear in the Proceeedings of Formal Methods in Software Practice, August 2000.

All of the above are available in the REQUIREMENTS SPECIFICATION AND ANALYSIS section of N.Leveson's papers page.

Human factors
  • "Designing Automation to Reduce Operator Errors", Nancy G. Leveson and Everett (NASA Ames Research Center). In the Proceedings of Systems, Man, and Cybernetics Conference, Oct. 1997.
  • "Describing and Probing Complex System Behavior: A Graphical Approach" by Edward Bachelder and Nancy Leveson. In the proceedings of the Aviation Safety Conference, Seattle, Sept. 2001.
All of the above are available in the HUMAN-MACHINE INTERACTION section of N.Leveson's papers page.
What I refer to as [Woo96] in lecture slides A. Wood. Predicting software reliability. Computer, 29(11):69--77, November 1996.

Available in our library.

Interesting parallels between present safety-critical systems development and high-pressure steam boilers of the past century. "High-Pressure Steam Engines and Computer Software" by Nancy Leveson. Presented as a keynote address at the International Conference Software Engineering in Melbourne Australia, 1992 and published in IEEE Computer, October 1994.

Available in the MISCELLANEOUS section of N.Leveson's papers page.

An article about parallels between conventional engineering and software engineering. "Software Engineering: A Look Back and A Path to the Future" by Nancy Leveson.

Available here.

The paper about the kind of faults in software development process which are most likely to lead to accidents. "Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems", Robyn R. Lutz, proceedings of the IEEE International Symposium on Requirements Engineering, Jan 4-6, 1993, San Diego, CA.

Available from Robyn R. Lutz's home page.

About formal methods and DO-178B in development of safety-critical systems (long one). This is the report mentioned in the slides under the name "SRI report". Formal Methods and the Certification of Critical Systems by John Rushby. Number SRI-CSL-93-7. Computer Science Laboratory, SRI International, Menlo Park, CA. December, 1993.

Available from here.

Kirill Bogdanov (replace _ in the email address with @)