Chris W. Johnson

What are emergent properties and how do they affect the engineering of complex systems

‘Emergent properties’ represent one of the most significant challenges for the engineering of complex systems. They can be thought of as unexpected behaviors that stem from interaction between the components of an application and their environment. In some contexts, emergent properties can be beneficial; users adapt products to support tasks that designers never intended. They can also be harmful if they undermine important safety requirements. There is, however, considerable disagreement about the nature of ‘emergent properties’. Some include almost any unexpected properties exhibited by a complex system. Others refer to emergent properties when an application exhibits behaviors that cannot be identified through functional decomposition. In other words, the system is more than the sum of its component parts. This paper summarizes several alternate views of ‘emergence’. The intention is to lend greater clarity and reduce confusion whenever this term is applied to the engineering of complex systems.

How will we get the data and what will we do with it then? Issues in the reporting of adverse healthcare events.

Incident reporting has been proposed as an important means of identifying and addressing the causes of human error in medicine, and initiatives to implement these schemes have been set up in many countries. However, incident reporting has its limitations. Many people have been too ready to believe the overstated claims about the effectiveness of incident reporting in other domains. Others have not listened to the more limited claims made by the operators of existing systems in aviation and in organizational health and safety applications. This paper argues that more attention should be paid to the problems of eliciting incident reports from a broad spectrum of healthcare workers. It is also argued that more sophisticated computation support should be recruited so that clinicians do not have to learn complex command languages when they want to search for common factors in those incidents that are submitted.

Why did that happen? Exploring the proliferation of barely usable software in healthcare systems

Clinicians and support staff are faced with increasingly complex computer applications. This complexity stems partly from the integration of heterogeneous systems ranging from computerized patient records to theatre management and dosage planning applications, and also from the increased functionality offered by the new generation of IT systems. Many members of clinical staff are bewildered by the vast array of configuration options and operating modes supported by computer based systems, while manufacturers often feel compelled to offer more and more software features to retain market position. These factors combine to create “usability” problems that have had a direct impact on patient outcomes as well as a number of indirect effects—for example, the costs of replacing and upgrading inadequate computer systems carry significant opportunity costs in terms of services that might otherwise have been funded. In the future we need to educate staff to reject substandard computer interfaces early in the acquisition process; encourage the use of human computer interaction techniques in health care; and train staff to recognize the dangers of “working around” poor interface design.

Lessons from the evacuation of the world trade centre, 9/11 2001 for the development of computer-based simulations

This paper reviews the state-of-the-art in evacuation simulations. These interactive computer based tools have been developed to help the owners and designers of large public buildings to assess the risks that occupants might face during emergency egress. The development of the Glasgow Evacuation Simulator is used to illustrate the existing generation of tools. This system uses Monte Carlo techniques to control individual and group movements during an evacuation. The end-user can interactively open and block emergency exits at any point. It is also possible to alter the priorities that individuals associate with particular exit routes. A final benefit is that the tool can derive evacuation simulations directly from existing architects, models; this reduces the cost of simulations and creates a more prominent role for these tools in the iterative development of large-scale public buildings. Empirical studies have been used to validate the GES system as a tool to support evacuation training. The development of these tools has been informed by numerous human factors studies and by recent accident investigations. For example the 2003 fire in the Station nightclub in Rhode Island illustrated the way in which most building occupants retrace their steps to an entrance even when there are alternate fire exits. The second half of the paper uses this introduction to criticise the existing state-of-the-art in evacuation simulations. These criticisms are based on a detailed study of the recent findings from the 9/11 Commission (2004). Ten different lessons are identified. Some relate to the need to better understand the role of building management and security systems in controlling egress from public buildings. Others relate to the human factors involved in coordinating distributed groups of emergency personnel who may be physically exhausted by the demands of an evacuation. Arguably, the most important findings centre on the need to model the ingress and egress of emergency personnel from these structures. The previous focus of nearly all-existing simulation tools has been on the evacuation of building occupants rather than on the safety of first responders.

A Survey of Logic Formalisms to Support Mishap Analysis

Abstract Mishap investigations provide important information about adverse events and near miss incidents. They are intended to help avoid any recurrence of previous failures. Over time, they can also yield statistical information about incident frequencies that helps to detect patterns of failure and can validate risk assessments. However, the increasing complexity of many safety critical systems is posing new challenges for mishap analysis. Similarly, the recognition that many failures have complex, systemic causes has helped to widen the scope of many mishap investigations. These two factors have combined to pose new challenges for the analysis of adverse events. A new generation of formal and semi-formal techniques have been proposed to help investigators address these problems. We introduce the term ‘mishap logics’ to collectively describe these notations that might be applied to support the analysis of mishaps. The proponents of these notations have argued that they can be used to formally prove that certain events created the necessary and sufficient causes for a mishap to occur. These proofs can be used to reduce the bias that is often perceived to effect the interpretation of adverse events. Others have argued that one cannot use logic formalisms to prove causes in the same way that one might prove propositions or theorems. Such mechanisms cannot accurately capture the wealth of inductive, deductive and statistical forms of inference that investigators must use in their analysis of adverse events. This paper provides an overview of these mishap logics. It also identifies several additional classes of logic that might also be used to support mishap analysis.

Using a formal language to support natural language in accident reports

Accident reports written by official bodies, such as the Air Accident Investigation Branch of the United Kingdoms Department of Transport, are produced in response to all major civil aircraft accidents or incidents. There are many statutory, legal and commercial implications that rest on the analysis, conclusions and recommendations that these reports contain. Air accident reports usually follow a standard format of synopsis followed by factual information, including history of flight and the systems involved, followed by analysis and conclusions. Finally, there are safety recommendations aimed at preventing a recurrence of the accident. Natural language is the primary means of communicating all of these findings. In requirements engineering there is an increasing recognition that natural language is not always an adequate means of expressing some of the detailed reasoning associated with the causal analysis of complex systems. Recent work in software engineering has explored the use of formal, mathematically based, techniques to help to gain the required level of clarity and precision. It is argued that accident reports, like requirements documents, could benefit by the use of formal techniques to complement the usual natural language descriptions. In this paper one specific accident report is considered. The limitations of its natural language descriptions are examined and the use of a Petri Net notation to help to elucidate its ambiguities is explored

Using temporal logic to support the specification and prototyping of interactive control systems

Abstract Accidents at Flixborough, Seveso, Bhopal, Three Mile Island, Windscale and Chernobyl have led to increasing concern over the safety and reliability of control systems. Human factors specialists have responded to this concern and have proposed a number of techniques which support the operator of such applications. Unfortunately, this work has not been accompanied by the provision of adequate tools which might enable a designer to carry it beyond the “laboratory bench” and on to the “shop floor”. The following paper exploits formal, mathematically based specification techniques to provide such a tool. Previous weaknesses of abstract specifications are identified and resolved. In particular, they have failed to capture the temporal properties which human factors specialists identify as crucial to the success or failure of interactive control systems. They also provide the non-formalist with an extremely poor impression of what it would be to like to interact with potential implementations. Temporal logic avoids these deficiencies. It can make explicit the sequential information which may be implicit within a design. Executable subsets of this formalization support prototyping and this provides a means of assessing the qualitative “look and feel” of potential implementations. A variety of presentation strategies, including structural decomposition and dialogue cycles, have been specified and incorporated directly into prototypes using temporal logic. Prelog, a tool for the Presentation and REndering of LOGic specifications, has been developed and its implementation is described.

Proving properties of accidents

Abstract Accident reports are produced by regulatory and commercial authorities, such as the UK Air Accident Investigation Branch and the US National Transportation Safety Board, in response to most major accidents. These documents are intended to ensure that disasters do not recur. They, typically, contain accounts of the human and system failures that lead to major accidents. These descriptions are then used to identify the primary and secondary causes of the failure. Finally, recommendations are made so that the operators and regulators of safety-critical systems can avoid future accidents. Unfortunately, it is often difficult for readers to trace the way in which particular conclusions are drawn from the many hundreds of pages of evidence in these reports. Natural language arguments often contain implicit assumptions and ambiguous remarks that prevent readers from understanding the reasons why a particular conclusion was drawn from a particular accident. In contrast, this paper argues that mathematical proof techniques can be used to support the findings of accident investigations. These techniques enable analysts to formally demonstrate that a particular conclusion is justified given the evidence in a report. In doing so, it is possible to identify missing pieces of evidence, to identify ambiguities and to determine which items of evidence are critical to particular lines of argument. The later sections of this paper then introduce Conclusion, Analysis and Evidence diagrams. These can be used to communicate the results of a formal analysis. The intention is not to replace the natural argumentation structures that are currently used in accident reports. Rather, our aim is to increase our confidence that particular conclusions are well supported by the evidence that is presented within a report. Finally, we show how CAE diagrams may be used in conjunction with design rationale techniques that have been proposed to support the design of safety-critical applications. This helps to ensure that findings about previous failures are propagated into the subsequent development of future systems.

Reasons for the Failure of Incident Reporting in the Healthcare and Rail Industries

Incident reporting systems have recently been established across the UK rail and healthcare industries. These initiatives have built on the perceived success of reporting systems within aviation. There is, however, a danger that the proponents of these schemes have significantly over-estimated the impact that they can have upon the operation of complex, safety-critical systems. This paper, therefore, provides a brief overview of the problems that limit the utility of incident reporting in the rail and healthcare industries.

Using Z to support the design of interactive safety-critical systems

Mathematically-based specification techniques are increasingly being recruited to support the development of safety-critical systems. Formal notations, such as Z and VDM, provide precise and concise means of representing a design without forcing commitment to implementation strategies during the early stages of development. Unfortunately, interface requirements are not normally considered within formal specifications. This threatens user-centred design. A prime objective in the use of formal methods is to minimise the modifications that are necessary once a specification has been refined towards implementation. Usability considerations therefore run the risk of being relegated to an afterthought in the development process. The paper argues that temporal and presentation issues must be represented within formal specifications of interactive systems. >