Systems Engineering and Safety Issues in Scientific Facilities Subject to Ionizing Radiations

Abstract

The conception and development of large-scale scientific facilities emitting ionizing radiations rely more on project management practices in use in the process industry than on systems engineering practices. This paper aims to highlight possible reasons for this present situation and to propose some ways to enhance systems engineering so that the specific radiation safety requirements are considered and integrated in the approach. To do so, we have reviewed lessons learned from the management of large-scale scientific projects and more specifically that of the Large Hadron Collider project at CERN. It is shown that project management and systems engineering practices are complementary and can beneficially be assembled in an integrated and lean managerial framework that grants the appropriate amount of focus to safety and radiation safety aspects.

Keywords

Project Management Systems Engineering Scientific Facility Management Radiation Safety

1. Introduction

Out of the four concerns of RAMS (Reliability, Availability, Maintainability and Safety), safety may impact the success of a project quite differently from the others because of the way its deliverables are assessed. While RAM requirements are associated with tangible deliverables, the “safety success” of a system relies on intangible deliverables. If, over its development and operations, there is no impact on people, no accident, and no impact on the environment, then a project is considered a success. However, in terms of RAM requirements, whose assessment is based on something happening, the “safety success” will not be seen because “nothing” tangible has happened. For this reason, stakeholders are usually keener to work out the RAM side of the project rather than the safety side. As a result, the four RAMS requirements should be addressed differently.

As exposed in the literature [1]–[3], systems engineering (SE) does not provide the means to handle this specificity. For instance, although the NASA SE Standard suggests that safety reviews be organized regularly, out of the 33 typical activities of the Concept and Technology Development Phase of a space project [2] (p. 23), safety is only mentioned in two of them. Out of the 21 typical activities of the Preliminary Design and Technology Completion Phase [2] (p. 24), only one is related to safety. Safety is addressed in Section 4.4 of this document [2] (pp. 63–64). In these few paragraphs it is suggested, for instance, that Failure Modes and Effects Analyses (FMEAs) or Preliminary Hazard Analysis (PHA) be performed. The situation is similar to that of the European Cooperation for Space Standardization (ECSS) brochures. According to ECSS-E-00A, safety is an activity carried out by the system supplier that is part of product quality assurance. The boundaries of this activity are not always clearly defined; for instance, product assurance includes reliability, availability, maintainability and safety activities [4] (p.15). Related to safety, an ECSS brochure is dedicated to this subject [5]. Safety is also scarcely introduced in IEEE Std. 1233 [6] (pp. 9-10). Literature related to systems engineering is abundant [1, 7, 8]. Of the few reviewed, all of them mention safety as an important requirement for the development of a complex system. For instance, Sage and Rouse consider safety as part of the “scientific and engineering effort” of SE, as transverse activities beside “reliability, maintainability, survivability, human engineering and other factors” [1] (p.13). It is also worth mentioning that none of the resources cited above introduces the two equivalent concepts of ALARA (As Low As Reasonably Achievable) or ALARP (As Low As Reasonably Practicable). These methods are related to radiation safety and concerned with the optimization of radiation doses received by personnel. They are of prime importance throughout the lifecycle of a particle accelerator facility, as will be shown further in this article.

In the present paper, we propose a framework to approach safety and in particular radiation safety coherently within the corpus of project management and of systems engineering more specifically. In addition to the introduction, this paper is composed of three sections: Section 2 briefly recalls what project management and systems engineering are, Section 3 summarizes systems engineering and project management requirements for the conception, development, operations and maintenance of scientific facilities emitting ionizing radiations; and finally, Section 4 proposes ideas towards an integrated systems engineering approach that would pay particular attention to radiation safety and hardware and software solutions to enhance this concern through the early-stage promotion of remote handling and robotics.

2. Project Management and Systems Engineering

2.1 Project Management

Even if some professional associations such as the US Project Management Institute [www.pmi.org] aim to homogenize practices, the project management corpus differs substantially depending on the professional domain it is applied to. One can typically observe different approaches for the eight following domains: construction, process industry, new product development, new service development, information and communication technologies, organization, events and human resource development. Research projects shall be considered separately as they do not completely fulfil all of the generally agreed definitions for projects in organizations. So-called scientific projects differ from research projects in the sense that they are aimed at providing means for performing research projects. In many research domains, scientific projects share many of the characteristics of industrial projects. This is the case for particle accelerator facilities that have many engineering aspects in common with process industry facilities, such as chemical plants or power stations. While “reasonable-size” projects belong typically to one of the eight domains mentioned above, large-scale scientific facilities are composed of sub-projects from all eight domains. Taking the CERN's Large Hadron Collider (LHC) as an example [www.cern.ch/lhc], its conception and development involved sub-projects from these eight domains:

Organization: The launch of this unprecedented large-scale project required an organizational effort. Before 1996, CERN's organizational structure was largely dictated by PS, SPS and LEP¹ particle accelerator operations requirements (function-oriented structure [9]). The approval of the LHC Project led CERN Management to review the organizational structure in order to facilitate the realization of this project (a mix of heavy-weight and light-weight project matrix structures [9]).

The construction of the LHC required extensive civil engineering work; huge underground caverns, kilometres of underground galleries and industrial and tertiary surface buildings. To succeed with these subprojects, the civil engineers wanted to legitimately implement state of the art practices of construction project management [10, 11].

New product development: the manufacture and assembly of some 1600 cryomagnets, for instance, required the implementation of enhanced plant engineering and operations management practices [9].

Process industry: The several cryogenics facilities that were constructed to deliver liquid nitrogen and liquid helium to the superconducting cryomagnets and accelerating cavities have a lot in common with industrial plants and cryogenics engineers are used to following project management practices from this project domain [12, 13]. So did the HVAC (Heating, Ventilation and Air Conditioning) and electrical engineers for the construction of the cooling plants and power distribution stations.

Information and communication technologies: the development of the many controls required to operate an accelerator relies predominantly on information systems project management practices. For instance, software engineers prefer agile project management methodologies such as Scrum [14].

In modern management understanding, a particle accelerator facility aims to deliver a service to the particle physics community: to enhance this objective, new service development project management practices were, to some extent, followed [15, 16].

The conception, development and construction of the LHC Project required the redeployment of many technicians, engineers and physicists as well as the recruitment of many project specialists. The success of these human-resource deployment and development projects was possible if and only if appropriate project management practices were implemented.

Event: Last but not least, it is not possible to succeed with these large-scale projects if they are not appropriately marketed. In April 2008, the LHC Open-Days welcomed about 80,000 visitors [http://cern.ch/lhc2008]. The success of such an event is subject to the implementation of good event project management practices.

The conception, development and construction of large-scale scientific facilities rely on the appropriate use of project management practices. However, these practices are not unique; they are widespread and specific to certain aspects of the project. Forcing all project contributors to implement a unique project management approach must have a rationale. Sharing a common core is a prerequisite for enhancing communication and coordination among project participants, although the definition of this is not straightforward. Some suggest the implementation of PMI's Project Management Body of Knowledge [17], which aims to describe project management practices suited to all types of projects. The recently released ISO 21500 Std. [18] “can be used by any type of organization, including public, private or community organizations, and for any type of project, irrespective of complexity, size and duration”. Both documents are general-purpose standards and not sufficiently specific to fulfil the expectations mentioned above and for that very reason can serve as a basis for the core framework, but cannot be the core framework. While the NASA's Systems Engineering Handbook [2] or the ESA's ECSS Standards [4] propose such a core framework for space projects, to our knowledge, nothing similar exists for large-scale particle accelerator projects and more broadly for scientific projects.

2.2 Systems Engineering

According to the International Council on Systems Engineering (INCOSE) [www.incose.org] “systems engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionalities early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: performance, cost & schedule, manufacturing, testing, operations, training & support, and disposal” [3]. In other words, SE can be seen as a subset of the project management corpus dedicated to the development of complex mechatronics systems.

As the PMI's Project Management Body of Knowledge [17] suggests, if appropriate attention is paid to the nine knowledge areas of project management, typically by implementing the suited management techniques, then project management teams substantially increase the chance of success of their projects. Several academic studies have confirmed that the implementation of standardized practices increases project success (see for instance Milosevic and Patanakul [19]). But other studies convey the contrary, such as that of Dvir, Raz and Shenhar [20]. To these authors: “The findings suggest that project success is insensitive to the level of implementation of management processes and procedures, which are readily supported by modern computerized tools and project management training. On the other hand, project success is positively correlated with the investment in requirements' definition and development of technical specifications”. The SE corpus is somehow in line with this conclusion: it suggests that particular attention be paid to the technical side of the project and according to the NASA's Systems Engineering Handbook or ESA's ECSS Standards, more specifically with these aspects:

Needs gathering (see NASA-SHE § 4.1 Stakeholder Expectation Definition [4] (pp. 33–39)) and requirement definition (see NASA-SHE § 4.2 Technical Requirement Definition [2] (pp. 40–48) or ECSS-E-00A § 6.2 Requirements Engineering [4] (p. 30) that consists of identifying who the stakeholders are, and what their intentions are towards the systems, before transforming these needs into a validated set of technical requirements expressed as “shall” statements.

Product/systems integration (see NASA-SHE § 5.2 Product Integration [2] (pp. 78–82) or ECSS-E-00A § 6.1 System Engineering Integration and Control [4] (p. 29) that consists of transforming lower-level components into higher-level systems and making sure that the integrated systems function properly.

Product/system verification (see NASA-SHE § 5.3 Product Verification [2] [pp. 83–97], ECSS-E-00A § 6.5 System Verification [4] [pp. 32-33] or ECSS-E-10-02a [21] dedicated to verification) and validation (see NASA-SHE § 5.3 Product Validation [2] [pp. 98–105]). Even if these two processes are not always described as such in all SE standards or textbooks, verification and validation are two distinct processes of prime importance for the success of a complex systems development project. Verification relates to the validated set of technical requirements by checking if the expected requirements are implemented and perform as expected; validation relates to stakeholders expectations by checking if these expectations are fulfilled at an overall system level [1] (§ 14.6.5 Role of Verification and Validation, pp. 557–558). It should be noted that verification and validation (V&V) are important components of the V-Modell [22] and are two distinct process areas of the CMMI model [23] where “verification ensures that you are building a product according to its requirements, specifications, and standards. For Verification, you should ask the following questions: Are you meeting the specified requirements? Are you building the product right?” while “validation ensures that your product will be usable once it is in its intended environment. For Validation, you should ask the following questions: Are you meeting the operational need? Does this product meet its intended use in the intended environment? Are you building the right product?” [http://cmmiinstitute.com/]

In conclusion, it should be highlighted that systems engineering complements project management practices by providing means to communicate and coordinate the technical dimension of the project. However, while systems engineering is particularly well suited for the conception and development of complex products that are made of subprojects of a mechatronics nature (mechanics, electronics, controls software), it has not been designed for complex facilities that will probably include civil engineering, process plants, new product/service developments, information and communication technologies. Both project management and systems engineering practices and standards provide insight into the processes to implement, including their lifecycles, into the stakeholders at large and their roles and into the outcomes of the various processes, in particular the key documents to release.

3. Developing Scientific Facilities Subject to Ionizing Radiations

The projects to which scientific facility developments are the most similar are industrial plant development projects implementing rather complex processes. For scientific facility projects that are subject to ionizing radiations like particle accelerator facilities, these are nuclear power stations (NPS) or nuclear waste reprocessing plants (NWRP) projects. Even if they might be similar in several aspects, they strongly diverge on some others, for instance:

NPS or NWRP are privately owned, whereas most large-scale scientific facilities are not. These two types of development projects balance the so-called project triangle differently (i.e., the trade-off between time, costs and performance to achieve [24]). For instance, the performance perspective of scientific facilities is superior.

The number of engineering disciplines involved in conceiving and developing large-scale scientific facilities is larger than that of an NPS or NWRP. It is also much larger than that of space engineering [4] (§ 5.3, pp. 24–25).

These aspects may not appear to be very selective, but in practice they are. Because of these specificities, the conception and development of scientific facilities are approached differently.

Among the specific requirements are those of the nuclear licensing authorities. Even if nuclear material is not necessarily present in scientific facilities that are subject to ionizing radiations, national nuclear licensing authorities are consulted before these facilities are brought to operation. In order to provide their clearance, these authorities have specific expectations regarding safety— i.e., workers should not fall victim to an accident or professional illness because of the facility or system. This concern is covered by occupational health and safety and integrity. In other words, the presence of the facility should not represent any hazard to the people or the environment. It should operate reliably towards the teams in charge of the conception and development and then those in charge of operations. They typically require that a file be developed and endorsed. This so-called Safety File, also called Safety Data Package [2] or [5] (pp. 49–50), shall provide a comprehensive description of the facilities, but also justifications of all choices towards solutions enhancing safety and integrity. This includes the application of the ALARA/ALARP approach and specific prescriptions towards the operations teams so that the facility is operated safely and the integrity of the facility is guaranteed.

3.1 Requirements from Licensing Authorities

As mentioned earlier, safety and integrity concerns are of prime importance in the conception, development and construction of scientific facilities, especially if they are expected to emit ionizing radiations. This applies to a facility when it is seen as a whole, but also equally to any of its sub-systems and components, whether they are developed in synchronization with the facility to which they belong, or afterwards as consolidation or upgrade projects. As a consequence, licensing authorities are very important partners in the process of preparing a facility or systems for operations and maintenance.

Even if they differ from one country to another, the expectations of the licensing authorities evolve as the global knowledge on nuclear and radiation safety management grows. Lessons learned from the operation of facilities on the one hand and near-accident and accident inquiries and analyses on the other, contribute importantly to the evolution of these expectations. However, since the mid-1990s, the so-called ALARA (As Low As Reasonably Achievable) or ALARP (As Low As Reasonably Practicable) principle has become a major expected result.

To understand the ALARA principle, one should investigate the concept of risk. According to etymologists, the noun “risk” possibly has several origins. It might be traced back to classical Greek “ριζα”, that means “root” or to the ancient Latin “risicare” that means “reef” or “snag”. In both cases, Sabelli [26] suggests that this understanding typically led to risk protection behaviour: one shall avoid the root on her/his pathway or the sailor shall protect her/his boat from grounding on a reef. The term “risk” can also be traced back to the Latin “rixa” that means “brawl” or “quarrel”. Sabelli explains that to survive or to protect their belongings, any one has to fight against others. These two possible etymologies clearly suggest that the concept of risk be understood from two opposite (antagonist) perspectives:

The “risk-snag”² perspective for which risk shall be cancelled or at least mitigated. This is typically the attitude safety engineers have had for many years;

The “risk-action” perspective suggesting that any one shall take reasonable risks.

Undoubtedly, the advent of safety management rose to address the “risk-snag” perspective. Consequently, from a pure teleological viewpoint, a straightforward way for avoiding these “risk-snags” consists of getting rid of all the activities and systems that are at the origin of the risks. If this reasoning is pushed to the extreme, in other words getting rid of all activities and systems, then it becomes evident that this tenet is incompatible with the goal of any organization that is creating value, or knowledge in the case of scientific institutions. The ALARA principle emerged from this necessity of mitigating “risk-snag” vs. “risk-action”: how far can we pursue the goal of any organization while keeping safety risks at a tolerable level? With respect to ionizing radiations and their consequences on workers, the ALARA principle can be set up in terms of how much resource the organization accepts to spend to reduce substantially the radiation risk towards its personnel and the population living in the area surrounding the facility.

In the field of radiation protection, the ALARA principle was raised from experimental cell biology observations: when subject to ionizing radiations, human body cells absorb energy. Consequently, three situations may occur:

If the deposited energy is low enough, the cells will repair themselves and no sanitary effects will be observed.

If the level of transferred energy is too high, the cells will not survive the radiation and will die.

In between, cell transformations are observed, but the boundary thresholds are very difficult to define and predict; in some situations some cells will repair, and in others they will die.

In addition, while the opposite survival processes are of a deterministic nature in that the outcome can be predicted, the intermediate one is of a pure stochastic nature: it is difficult to predict the consequence of the radiation for the cells on the medium- or long-term. Because of this, it is impossible to define a radiation dose and a dose rate threshold below which there is undoubtedly no risk. Radiation protection experts suggest that a trade-off approach that advocates the implementation of all possible protective and preventive measures, so that the radiation risk reaches a tolerable level in the spirit of the “risk-snag” vs. “risk-action” trade-off exposed before, is preferable.

Practically, implementing the ALARA principle consists of foreseeing several solutions to perform an activity that contributes substantially to its value generation process, and to set up the most acceptable trade-off between the cost of implementing high-end solutions that definitively lower risks and may be less costly solutions that present certainly more risks but which are fully acceptable, i.e., well below tolerable risks and within legal provisions [27, 28]. For instance, remote-controlled interventions by means of telerobotics systems in ionizing radiation areas are necessarily seen as more expensive as they require investment compared to more straightforward human interventions.

As ALARA is globally accepted as a principle, licensing authorities have within their mission the duty to verify that all organizations at risk for their personnel, the surrounding local population and the environment implement this principle. As is often the case in matters of quality assurance, the concerned organizations shall provide evidence of appropriate implementation by providing the proper documentation of the processes followed. In this way, the safety documentation management process becomes important.

3.2 Organizing Safety

There is no definitive approach to organizing safety in an organization. Nevertheless, because safety and environmental concerns have taken a central position in the ethical behaviour of many organizations, one can easily observe that, because the stakeholders are many (the management of the organizations, as well as members of their personnel, trade unions, local communities, local and national authorities) organizations have developed a “democratic behaviour” towards these concerns. The results of these observations are the emergence of the principles of Montesquieu. In The Spirit of Laws written more than two centuries ago [29, 30], Montesquieu argues that the concept of democracy relies on the separation of power between the legislature who makes the laws, the judiciary who punishes those who do not respect the law, and the executive who manages the community with the boundaries defined by the laws.

Translated into the safety-related vocabulary of organization, this means that by analogy with the three powers from Montesquieu:

Organizations shall develop their own set of safety rules and set up international and national laws on the one hand, and on official and professional standards on the other

Organizations shall create their own inspection bodies to ensure that the safety rules are correctly implemented

Any member of the personnel of the organization and stakeholders at large shall carry out their tasks in conformity with the safety rules.

The implementation of safety measures is then the duty of everyone and not a matter to be kept with safety experts. Since quality principles shall also apply to safety, everyone shall document safety to prove that the appropriate safety provisions have been considered and implemented.

3.3 Safety Documentation Management

Especially when the facilities and industrial processes are complex, featuring specialized technologies, the safety documentation that is expected has three purposes [31] that lead to the three parts of the safety documentation:

Descriptive: one part of the safety documentation shall describe succinctly, the facility, systems, equipment, process, activity, etc., in words that can be understood by anyone with a general engineering knowledge. The questions to be answered in this descriptive part are typically: Why is it useful? Where is it located? What is it made of? How does it work? When will it be constructed, operated, dismantled? Who is responsible for its development, construction? How will it be developed, constructed? Who will be responsible forits operation, maintenance and dismantling? How will it be operated, maintained and dismantled? And last but not least, which hazards are present in the facility/process?

Demonstrative: the second part provides evidence that the safety provisions, either foreseen or implemented, either preventive or protective, either technical or organizational, are sufficient to avoid or mitigate the risks down to a tolerable level or even below. All the safety risks that have been identified and assessed are listed in this demonstrative part, including the corresponding risk analyses, the ALARA processes conducted and the technical and organizational risk control measures.

Prescriptive: the third part describes the safety rules to follow, and the technical and organizational provisions to implement to develop, construct, operate, maintain and dismantle the facility, systems and equipment. Practically, this part collects all the manuals, instructions, procedures and all other appropriate documents to conduct the tasks listed above, including the appropriate quality management framework.

Records, including monitoring data, lessons learned and improvement write-ups may constitute the fourth part to the safety documentation.

The release of this documentation shall be synchronized with the facility lifecycle. During a study phase, this safety documentation may only consist of a preliminary descriptive part and of an initial demonstrative part. These components are important in the process of deciding whether or not to implement a project. The prescriptive part is prepared while the project is being developed. One part of the manuals, instructions and procedures is likely to be dedicated to the construction of the facility, systems or equipment. The rest addresses operations, maintenance and dismantling requirements. Finally, records and lessons learned are collected after safety reviews and inspections are launched. Figure 1 synthesizes this synchronization of documents.

Figure 1.

CERN's approach to safety documentation management [31].

4. Integrating Radiation Safety Concerns with Systems Engineering

Scientific facilities are complex systems, and the management of their conception and development can definitively benefit from SE practices. But to do so, it is necessary to embed radiation safety requirements in the SE corpus. On the one hand, the V-Modell depicts the SE process (see Figure 2) well. On the other hand, CERN's approach to safety documentation management, as shown for instance in Figure 1, fulfils expectations in matters of safety information handling. Prosaically, integrating radiation safety requirements as expected by all stakeholders of a scientific facility emitting ionizing radiations may consist of an overlap of these two visual concepts.

Figure 2.

The systems engineering V-Modell.

Since SE practices complement project management ones by providing specific insights on need gathering, solution finding and writing the requirements, and on enforcing continuous verifications and validations, the issue becomes how radiation safety concerns can be combined with these SE sub-processes. This has been visually expressed in Figure 3 and is developed in the following sections.

4.1 During the Project Front-End Phase

Radiation safety concerns shall be fully integrated in the needs gathering exercise from the project front-end phase. Collecting needs consists of identifying stakeholders' expectations of the complex systems to develop from several perspectives: technical needs (typically functions to fulfil, performance to achieve, interfaces to accommodate, technical feasibility); development needs (project feasibility, manufacturability, constructability) and operational needs (typically strategic alignment, economic feasibility, reliability, availability, maintainability). Collecting safety needs, including environment protection needs, is the fourth perspective.

Solution finding, i.e., working out concepts that may fulfil needs is a process that takes place in parallel to needs gathering. For complex systems, needs can be gathered, i.e., a “needs portfolio” can be assembled, only if one already has some ideas of possible solutions. Concepts result from needs, but some conceptualization of possible solutions is required to gather needs exhaustively. Needs gathering and concept generation are two processes that are to be synchronized.

Needs shall be expressed in “stakeholders' words”, but a complex system development project is likely to involve tens to hundreds of contributors who may not necessarily have consistent and coherent expectations. Such a project expressed only in “stakeholders' words” is impossible to coordinate. Lessons learned have shown [9, 32, 33] that expressing needs statements as “shall” requirements is a prerequisite to guarantee the success of a project. While needs can be kept expressed in a rather informal and vague manner to be endorsed by the stakeholders who have a holistic vision of the outcome of the project, but not necessarily an in-depth understanding of all the disciplines involved in the proposed concepts, they are insufficiently precise to ease the coordination and integration of the many sub-systems. Requirement statements are derived from needs. Requirements translate in a straightforward way the expectations of the stakeholders. Since requirements shall be focused on the outcome of the development project, their identification is feasible only out of one or a few preferred concepts. The concepts are worked out and tuned until the list of requirements is stabilized and endorsed by the stakeholders.

These three activities (needs gathering, concept workout and requirement writing) form the core of the project frontend phase. Even if they are to be performed in a given sequence, these activities should be approached in a holistic way. With many scientific projects, the deliverable of this phase is called Concept Design Report (CDR).

To accommodate safety needs and requirements, this document should at least dedicate a safety annex assembling preliminary descriptive and demonstrative parts. To make this annex consistent, some preliminary ALARA analyses may be needed.

Later on, while the development project is ongoing, it is necessary to check and validate the fulfilment of these needs and requirements. This is the purpose of the validation activity operationally supported by a Validation Plan (VAP) and Validation Reports (VAR). All these documents should have safety-dedicated sections.

4.2 During the Project Development Phase

As suggested by several project management [34, 35] and systems engineering methodologies [1 –4, 7, 8], for obvious managerial reasons, it is wise to break this main phase down into three sub-phases: the definition phase dedicated to the engineering design of the solution; the development phase itself that consists of implementing the engineered solution, including manufacturing, assembling, integrating, coding, etc. and the deployment phase that aims to transfer the systems developed to those who have a duty to operate and maintain them.

For many scientific projects, the delivery of the definition phase is called a Technical Design Report (TDR). As for the CDR, this document should have at least one annex dedicated to safety, complementing the descriptive and demonstrative parts of the CDR and featuring some elements of the prescriptive part. Additional or enhanced ALARA analyses are likely to be conducted during the definition phase and appended to the TDR. During this phase, remote handling and robotics options are typically considered and engineered.

Out of the definition phase outcome, each engineering discipline should be capable of pursuing the development in relative autonomy. Two cases may arise:

Either the sub-system to develop is still perceived as a complex system, in which case it may be wise to carry out the SE process described above on this system, i.e., going through a project front-end phase, followed by a definition phase and a development phase in a kind of “fractal approach”. From a quality assurance point of view, a dedicated CDR may be needed and released, with a dedicated annex related to safety.

Or the sub-system can be seen as an engineered set of components to manufacture and assemble. From an SE documentation point of view, the team in charge of the development of this assembly is expected to release a so-called Manufacture and Assembly File (MAF) providing insights on the detail design of the set of components, on the manufacture and assembly instructions, procedures and quality records. The MAF shall be enhanced with a safety annex complementing the descriptive and demonstrative parts of the TDR safety annex, and expending the prescriptive part of this report.

Once the set of components and sub-systems are materialized, the project team can proceed with their integration. Quality assurance then aims to ensure that this integration work provides the expected results from the systems design. This is the purpose of the so-called verification activity. In practice, verification is planned with a Verification Plan (VEP) then followed up with Verification Reports (VER) as deliverables. All these documents shall have safety-dedicated sections.

Last but not least, the deployment phase that has four main focuses in practice: moving the complex systems into operation and ramping them up until expected performance levels are reached [9]; transferring the knowledge acquired all along the conception and development of the project to the teams who will be in charge of the operations and maintenance; editing the various operations and maintenance manuals (O&M); and finalizing the safety documentation.

Figure 3.

Integrating Radiation Safety Concerns with Systems Engineering.

5. Conclusion

In this article, we have shown that it is possible to assemble the key concepts of project management, of systems engineering and those of safety documentation management. Some project management and systems engineering methodology suggest releasing tens of different types of documents. We are convinced that a few key documents, such as the CDR, TDR, MAF, VAP and VAR, VEP and VER, and O&M Manuals, are sufficient to structure the framework of the technical documentation. This can then be appropriately complemented by a safety documentation broken down into four parts (descriptive, demonstrative, prescriptive and records), and by a few project management documents (project proposal/mandate, project management plan and progress and close out reports). This lean documentation framework is sufficient to guarantee the successful conception and development of a scientific facility or system.

Footnotes

1

Besides the Large Hadron Collider, the Proton Synchrotron, the Super Proton Synchrotron and the former Large Electron Positron collider, are or were major CERN particle accelerators.

2

Translated from the French “risque-écueil”.

References

Sage

A. P.

Rouse

W. B.

, Eds., Handbook of Systems Engineering and Management. Wiley-Interscience, 1999.

Kapurch

S. J.

, “NASA Systems Engineering Handbook,” NASA Headquarters, Washington, DC, 2007.

INCOSE, “Guide to the Systems Engineering Body of Knowledge.” [http://g2sebok.incose.org].

ECSS, “Space Engineering: Policy and Principles,” European Coordination for Space Standardization, Noordwijk, NL, Standard ECSS-E-00A, 1996.

ECSS, “Space Product Assurance: Safety,” European Coordination for Space Standardization, Noordwijk, NL, Standard ECSS-Q-40A, 1996.

IEEE, “Guide for Developing System Requirements Specifications,” The Institute of Electrical and Electronics Engineers, Inc., New-York, NY, Standard IEEE Std. 1233, 1998.

Kossiakoff

Sweet

W. N.

, Systems Engineering: Principles and Practices. Chichester: John Wiley & Sons, 2003.

Stevens

Brook

Jackson

Arnold

, Systems engineering: Coping with complexity. London: New York: Prentice Hall Europe, 1998.

Ulrich

Eppinger

, Product Design and Development, 5th ed. New-York, NY: McGraw-Hill/Irwin, 2011.

10.

PMI Standard Committee, Construction Extension to the PMBOK Guide, 2nd ed. Newton Square, PA: Project Management Institute, 2005.

11.

Halpin

D. W.

, Design of Construction and Process Operations. Chichester: John Wiley & Sons, 1976.

12.

Lawson

Wearne

Iles-Smith

, Project Management for the Process Industries. Rugby, Warwickshire, UK: Institution of Chemical Engineer, 1999.

13.

Whittaker

, Project management in the process industries. Chichester: John Wiley & Sons, 1995.

14.

Schwaber

, Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004.

15.

Bachy

Hameri

A.-P.

, “What to be implemented at the early stage of a large-scale project,” International Journal of Project Management, vol. 15, no. 4, pp. 211–218, 1997.

16.

Bachy

Hameri

A.-P.

Lindecker

Nordberg

, “L’ évolution de l'organisation dans un environnement multiprojet à grand échelle,” in Projectique: à la recherche du sens perdu, Paris, France: Économica, pp. 185–196, 1996.

17.

PMI Standard Committee, A Guide to the Project Management Body of Knowledge, 4th ed. Newton Square, PA: Project Management Institute, 2008.

18.

ISO, “Guidance on Project Management,” International Organization for Standards (ISO), Geneva, Switzerland, Standard ISO 21500:2012, 2012.

19.

Milosevic

Patanakul

, “Standardized project management may increase development projects success,” International Journal of Project Management, vol. 23, no. 3, pp. 181–192, 2005.

20.

Dvir

Raz

Shenhar

A. J.

, “An empirical analysis of the relationship between project planning and project success,” International Journal of Project Management, vol. 21, no. 2, pp. 89–95, 2003.

21.

ECSS, “Space Engineering: Verification,” European Coordination for Space Standardization, Noordwijk, NL, Standard ECSS-E-10-02A, 1998.

22.

Whytock

, “The Development Life-Cycle,” in Systems Engineering: Principles and Practice of Computer-Based Systems Engineering, Chichester: John Wiley & Sons, pp. 81–96, 1992.

23.

“CMMI Institute - the home of Capability Maturity Model Integration,” CMMI Institute. [Online]. Available: http://cmmiinstitute.com/.[Accessed: 14-Jan-2013].

24.

Morris

Hough

G. H.

, The Anatomy of Major Projects: A Study of the Reality of Project Management, 1st ed. John Wiley & Sons, 1988.

25.

DiNucci

, “Fragmented Future,” Print, vol. 54, no. 3, pp. 32, 221–222, 1999.

26.

Sabelli

, “Les risques de l'économie, l'économie des risques: Le point de vue de l'anthropologue,” presented at the 7e Congrès de la Société Suisse de Management de Projet, Lausanne, Suisse, 1999.

27.

Rimington

J. D.

, “The Tolerability of Risk from Nuclear Power Stations,” Health and Safety Executive, London, UK, 1988.

28.

Remill

, “ALARA Explored,” University of Newcastle, Computing Sci. Dept., Newcastle upon Tyne, UK, Technical Report Series CS-TR-1197, 2010.

29.

de Montesquieu

C.-L. de S. Baron

, The Spirit of Laws, vol. 1, 2 vols. Glasgow, UK: D. Niven, 1793.

30.

de Montesquieu

C.-L. de S. Baron

, The Spirit of Laws, vol. 2, 2 vols. Edinburgh, UK: Donaldson & Reid, 1762.

31.

Bonnal

Weisz

, “Safety Documentation Management,” CERN, Geneva, Switzerland, 2012. [http://edms.cern.ch/document/1177755].

32.

QFD, the Customer-Driven Approach to Quality Planning and Deployment. Tokyo, Japan: Asian Productivity Organization, 1994.

33.

Hauser

J. R.

Clausing

, “The House of Quality,” Harvard Bus. R., p. 11, 1988.

34.

FSUIT, HERMES Foundations: Management and Execution of Projects in Information and Communication Technologies. Bern, Switzerland: Swiss Federal Strategy Unit for Information Technology, 2003.

35.

OGC-UK, Managing successful projects with PRINCE2. London: UK Office of Government Commerce, 2009.