CONTEXT

 Noteworthy aspects of the CAS include its;

 
1. size (over 30,000 systems serving 2,000 operators),
2. diversity (several hundred subsystem procurement and installation projects over many years),
3. geographic scale (1.5 billion hectares from the Pacific coast to the mid-Atlantic and from the Great Lakes to the North Pole),
4. scope (2,000 sites across Canada including 58 towers, 102 Flight Service Stations, 2 Terminal Control Units, and 7 Area Control Centres plus several regional and national facilities),
5. time scale (to the year 2005 and beyond),
6. cost (expected to exceed $4 Billion by 2000),
7. diverse communications requirements (voice, data, navigation, fixed, mobile, far north, mid-ocean),
8. large user community with varying requirements for levels of service.

 In 1989, the Canadian Government Department of Transport embarked on a System Engineering and Integration Project to formalize the processes for the definition of requirements and the evolution of the system design of the CAS. As air navigation is a continuing business, a "clean-sheet" design is not possible. Every design decision flows to some extent from today's system in an evolutionary rather than revolutionary manner.

 Transport Canada uses the normal sequence of system engineering steps shown in Figure 1:
 
 

1. Understand mission needs


2. Develop the operating concepts

 
3. Specify system requirements

 
4. Specify the system design

 
5. Develop a transition plan

Much has been published on the development and maintenance of large requirements databases but there has been little discussion on the derivation of those requirements. In this paper I will concentrate on step 2 in the standard process - the techniques we use to develop and maintain the operating concepts.
 
 

UNDERSTAND MISSION NEEDS

 A very structured format was chosen to document ANS services. Each is stated in the form: "The air navigation system shall..." which helps ensure that it is written from the point of view of a user who is outside the system. Each statement is a concise, single sentence describing the "what" of a system service followed by the precise but high-level details of that service. An example is:

 "The ANS shall provide to user aircraft in flight a volume of conflict free airspace."

 The "how" is described later in the form of Operating Concepts.
 
 

THE CONCEPTS

 The concept documents provide a system model which:
 
 

1. describes the functional involvement of the operators and users of the system;
2. defines the facilities and operational positions within those facilities from which services are to be provided;
3. specifies the flow of information through the system in support of defined services from the source to the user of the data;
4. allocates the data processing functions to either human or machine;
5. reflects future technologies and demands and is readily revised as they evolve;
6. represents a consensus among concerned operational, technical and user agencies;
7. is based on and is fully traceable to the operations requirements document; and
8. forms the basis for development of detailed system-level functional requirements.

 Both documents describe the relevant concepts from the point of view of the user expectations of the CAS. For each operating position (such as "Radar Controller" or "Maintenance Supervisor") every required function of the position is tabulated to describe the expected machine inputs and outputs. We must keep in mind, though, that the system design is targeted at 10 years in the future so the concepts describe the future work of the operators and users of the equipment, not the way it is done today.

 Where do these concepts come from? As the system we are defining will evolve from today's system, it is clear that many of the concepts will be based on today's concepts. A number of the concepts are defined for us by ICAO, the International Civil Aviation Organization.

 We also recognize that many concepts first appear as something an operator saw at a trade show or read about in a magazine. Proposed concepts are often driven by "what can now be done through technology" as much as by "what we really need to do".

A major task for the concept design team is to consider the various concept alternatives and to decide on the most efficient and cost effective options, including quantities and locations for various facilities.

 Concepts are evaluated through discussions with users and operators, operational simulations, formal task analysis and structured trade-off studies. All evaluation teams take pains to avoid describing hardware, software or product specific solutions. There is plenty of opportunity for that later.

 All the concepts treat the entire CAS as a single "black box" that is defined in terms of input and output. The precise algorithms for linking specific inputs and outputs are not described at this point, nor are the specific pieces of equipment or sub-systems.

 Similarly, the concept documents do not discuss the details of the Computer/Human Interface (CHI). It is important not to get mired in details such as the size of the window on the display or the colour of the characters or the switch at this time. Those are implementation details that are best determined through extensive human factors prototyping and testing in a simulated operational environment.
 
 

CONCEPT DOCUMENT CONTENTS

 Section 2. The second section identifies those services to be provided by the system. Each service is as defined in the Operations Requirement Document and information is provided on to whom, by whom, and how the service may be provided. This section also describes any special technology that is to be employed as mandated by international agreement. The information is provided in an easily understood and concise textual form that requires only about one page per service.

 Section 3. The third section is broken into three parts, the context description, the system model and the operational scenarios. The first two parts use formal data flow graphical design and documentation techniques. The context diagrams define all the external entities that communicate or interact with the CAS while the system model describes staffed and unstaffed facilities, logical workstation positions and activities required to deliver the required services. This is the point at which it becomes essential to make use of efficient software tools for modelling the system and maintaining the data dictionary. All functions associated with each workstation are allocated to human, machine or procedure and tabulated for review. This tabulation defines implicitly where human/machine interfaces occur. These interfaces are tabulated separately in terms of form (text input, graphic display, alarm etc.), description and stimulus.

 The operational scenarios were devised to demonstrate the sequential flow of activities in the future ANS and provides an opportunity for the user and operator experts to validate the specific ideas expressed in the rest of Section 3. The scenarios are as detailed as possible and include, for example, references to specific airports and air routes to facilitate accurate visualization by the reviewers. The set of scenarios were crafted to exercise every facility and function and a cross reference table is included.

 Appendices. The concept document contains several appendices, the most important of which is the traceability matrix which is organised on a function by function basis to trace back to the high level service requirements. This information are not now required in paper form as good software requirements management tools enforce and manage requirements traceability.

 A second major appendix captures those future operating concepts that were known to be imminent but which were not adequately defined by international bodies for inclusion in the system design at this time. They will be re-evaluated and included as necessary at a later date.
 
 

CONCLUSION - LESSONS LEARNED

• It was necessary to have the system concepts defined in several different ways: graphically, in text form, and in structured tables. We found that the various types of reviewers (managers, pilots, controllers, engineers and technicians) have very different ways of viewing the world and could work most efficiently with the presentation format the came closest to their past experience.
• It is essential to have (and to use!) good automation tools for maintaining the databases that are developed during the design process. Paper documentation was essential as most reviewers did not have direct access to the software. Efficient production of the paper copies was a major requirement for the software tool.
• The concepts were developed by teams that included users, operators and technical personnel. A lot of time was spent on agreeing to certain critical definitions in the beginning but once that was accomplished, and the results were recorded for future teams, the work progressed quickly. Those definitions were carried on to later design stages and, as a side effect, a glossary/lexicon was produced for use throughout the organization.
• As this is not a one-time design for a system to be built and "sold off", it is essential that the change review and configuration management processes be carefully and fully documented. These processes will be used by many team over the years to modify the concepts and thus change the system design.
• To avoid re-inventing the design it is important to record and cross reference the concept evaluations and trade-off considerations as the studies are carried out. The final document displays the results to the world but the interim decision support materials are as important and must not be lost.
• While it is important to use the software tools to collect all the data necessary to support follow-on work, it is also important to collect no more than necessary. Extra data in a database must be maintained, at a significant cost. Requirements for the form and content of the stored data should be carefully defined. Be sure you know what each data item will be used for and how it will be used. In other words, don't forget to Systems Engineer the Systems Engineering System!

BIOGRAPHY