Rui Xue

Claude Baron

Philippe Esteban

Hamid Demmou

Managing Systems Engineering Processes: a Multi-Standard Approach

Keywords:

Considering that system design becomes more and more complex to manage, systems engineering standards are useful and necessary for the companies. In order to choose the right standard, this paper presents an analysis of and a detailed comparison between the current releases of the main Systems Engineering standards in system design industry, ANSI/EIA-632, ISO/IEC-15288 and IEEE-1220, and illustrates how to choose a standard on the basis of specific characteristics of the project. For cases where no standard completely satisfies the criteria, we suggest a way to extend and adapt a standard.

INTRODUCTION

Since 1969, many systems engineering (SE) standards have been drawn up in different fields of application, such as military, aeronautics, automatic and management. The ANSI/EIA-632 [START_REF]ANSI/EIA Standard for Processes for Engineering a System[END_REF], ISO/IEC-15288 [START_REF]ISO/IEC/IEEE Systems and Software Engineering -System Life Cycle Processes[END_REF] and IEEE-1220 [START_REF]IEEE Standard for Application and Management of the Systems Engineering Process[END_REF] standards play the most important roles. For companies, it is very important to choose the right standard for successful system development. As many changes have been introduced in current SE standards by the latest releases and as the goals and scopes differ from one standard to another, engineers and managers need help in understanding and analyzing the similarities and the differences between the SE standards when choosing the standard to follow. Few papers deal with the comparisons between the current releases and the evolution of SE standards.

The purpose of this paper is to present an analysis and a detailed comparison between the current releases of SE standards and to illustrate how to choose an SE standard on the basis of specific criteria. For this purpose, we explain how and why we selected an SE standard in one of our research case studies. As the chosen standard did not completely satisfy our selection criteria, we had to find a way to extend and adapt this standard. This paper thus gives the results of a multi-standard reference, based on the contents of two SE standards, mainly according to the following criteria: coverage of the system life cycle, abstraction level, relationships between the processes, and the validation & verification processes.

The paper is organized as follows: Section II introduces the three main systems engineering standards. Section III compares them, Section IV analyses these standards and illustrates how to make a choice between them according to specific criteria; it also suggests extensions for adapting a standard with elements from other standards. Section V summarizes and discusses the different contributions of this paper.

II. A QUICK SURVEY OF THE SYSTEMS ENGINEERING STANDARDS

A. The ANSI/EIA-632:1998 standard This standard is intended to provide a set of fundamental processes to guide developers in engineering a system [START_REF]ANSI/EIA Standard for Processes for Engineering a System[END_REF]. It focuses on the SE of enterprise-based systems [START_REF] Sheard | Systems engineering standards and models compared[END_REF] [START_REF] Martin | Overview of the EIA 632 standard: processes for engineering a system[END_REF]. Fig. 1 gives the structure of EIA-632; it defines 13 processes, organized into 5 groups. For each group, the standard gives the relationships between the processes included in the group. One of the most useful features of this standard is the close connection between processes; they are coordinated throughout the project, even if it makes the allocation of responsibility to the different processes more difficult [START_REF] Martin | Processes for engineering a system: an overview of the EIA 632 and its heritage[END_REF]. The standard aims to describe activities and tasks at a high level of abstraction. However, its goal is not to specify the details of "how to" implement process requirements for engineering a system, nor does it specify the methods or tools a developer would use to implement the process requirements [START_REF]ANSI/EIA Standard for Processes for Engineering a System[END_REF]. The high abstraction level of task gives more flexibility to the developer for engineering a system because constraints on tasks are less detailed. It thus offers a wide range of applications.

B. The ISO/IEC-15288:2008 standard

This standard was the first international standard to provide a comprehensive set of life cycle processes for most man-made systems [START_REF] Roedler | What is ISO/IEC 15288 and Why Should I Care?[END_REF]. Its purpose is to provide a defined set of processes to facilitate communication among the acquirers, suppliers and other stakeholders in the life cycle of a system [START_REF]ISO/IEC/IEEE Systems and Software Engineering -System Life Cycle Processes[END_REF]. Figure 2 shows the structure of it; it organizes processes into 4 groups: agreement processes, organizational projectenabling processes, project processes and technical processes, 25 processes in all. It describes systems engineering at the process level [START_REF] Roedler | What is ISO/IEC 15288 and Why Should I Care?[END_REF]. This standard covers the system's entire lifecycle, from conception through to retirement of the system, and the processes that cover all the stages. It describes the activities in detail. But it does not prescribe, provide or specify systems engineering methods or procedures to address detailed process requirements for the application of this standard.

C. The IEEE-1220:2005 standard

The purpose of this standard is to manage a system from initial concept through development, operations, and disposal. The scope covers the entire system life cycle, while nonetheless focusing more on product development than on life cycle definition and implementation. In this respect, it was more detailed than the EIA-632 and IEC-15288 standards, but this very detailed description makes the standard less versatile.

Figure 3 shows the structure of the standard, which defines 14 general requirements, 6 stages and 8 processes. The latest version considers the context of the system, and the systems engineering management plan. The use of this standard in complement to the ISO/IEC-15288 standard also addressed.

D. Conclusion on the three standards

All standards describe good systems engineering practices. Standards say what should be done, but try not to say how to do it. They therefore focus on processes and their related activities on requirements ('what'), rather than on methods and tools ('how'). They may suggest a life cycle to provide a context for their recommendation, although most specify their suggested life cycles as 'example'. They also vary their focus in a way that mirrors the change in industry outlook [START_REF] Sheard | Systems engineering standards and models compared[END_REF]. In short, the EIA-632 standard is more suitable for engineering enterprise-based systems; it focuses more on the technical management, validation and verification aspects. The IEC-15288:2008 standard is more suitable for engineering complex systems, especially projects that cover an entire system life cycle. The IEEE-1220 standard focuses on the development stage rather than the system life cycle or the technical management aspects.

III. COMPARISON OF THE THREE CURRENT STANDARDS

The EIA-632, IEC-15288 and IEEE-1220 standards are the most important. Obviously there are many differences between the standards. For developers, coverage of the system life cycle is one of the most important criteria for selecting a standard. The abstraction level of the processes or the activities is another important metric because it influences the flexibility and the expandability of the standard, which are inversely proportional to its abstraction level. The different focuses also influence the choice of standard [START_REF] Dorqnm | compliance frameworks systems engineering standards[END_REF]. For example, if the company wants to develop a small hardware system, it may choose the IEEE-1220 standard, because it describes the development stage of systems engineering more detailed. But if the company wants to develop a large software system, that may last for ten years, maintenance and retirement considerations will also be very important for the reengineering the system; it may prefer the IEC-15288 standard. Table I presents the most important differences between standards, according to comparison criteria defined in [START_REF] Sheard | Systems engineering standards and models compared[END_REF]. The system life cycle on which the EIA-632 standard relies is enterprise-based; it defines more stages referring to the enterprise. The focus is on systems and products in general; its concern is implementing the requirements of the standards within a defined engineering life cycle, which can be applied in any enterprise-based life cycle stage to engineer or reengineer a system. The IEC-15288 standard covers man-made systems; the focus is on a set of generic processes applied as appropriate to accomplish the purposes of any one of the phases of a system's life cycle. The IEEE-1220 standard also focuses on systems and products and more precisely on the development stage of the system life cycle, but adds focus on the enterprise (large organization) as well.

• Conception • Development • Production • Utilization • Support • Retirement • System definition • Preliminary design • Detailed design • FAIT (Fabrication,
Considering the level of detail, the EIA-632 standard describes the system life cycle at a requirement description level. It is more detailed than the IEC-15288, which describes the system life cycle at a process description level. The IEEE-1220 focuses on the practice for engineering a system, especially the development stage; it defines purpose, tasks and outcomes in more detail than the EIA-632. This last focuses on the conception stage; it adds more processes on the assessment of opportunities and the investment decision. IEC-15288 describes the processes at the highest detailed level. Activities, tasks and outcomes are also defined in the EIA-632, but they are less detailed than in the IEC-15288. The IEEE-1220 standard describes the processes at the least detailed level.

The EIA-632 defines the context for application of the standards as the external environment (laws, social responsibilities), enterprise environment (local culture, domain technologies) and the project environment (plans and tools) [1] [4]. The three standards cover different contexts of the project. The EIA-632 covers a small enterprise environment and the project environment, while the coverage of the environment in IEC-15288 is larger than the other two standards; it covers both the enterprise environment and the project environment. But IEEE-1220 only covers the project environment.

IV. CHOICE OF A STANDARD

A. Our research objectives

Nowadays, project management is becoming more and more complex, with the increasing number of partners, the heterogeneity of contributions and the complexity of the systems being developed [START_REF] Boarder | Global Engineering Management: Emerging Trends in the Asia Pacific[END_REF] [START_REF] Rhodes | Systems engineering leading indicators for assessing program and technical effectiveness[END_REF]. Our research addresses collaborative engineering questions; our goal is to improve and facilitate coordination between system engineers and project managers, providing them with a method and a tool. Thus we consider processes invoked during the development stage in SE standards, such as the requirements definition process, solution definition process, requirement validation process and the system verification process, and similar processes from the Project Management Body Of Knowledge (PMBOK) [START_REF]IEEE Guide-Adoption of the Project Management Institute (PMI) Standard A Guide to the Project Management Body of Knowledge (PMBOK Guide)-4th Edition[END_REF], a guide which provides guidelines for project management, such as project management processes, project integration management and project risk management. Although SE fixes a few principles and milestones, it does not offer a set of generic processes to monitor project progress, so that the project manager and the project team are required to implement the processes based on the PMBOK methodology. However, some conflicts remain between the processes in the SE standards and the PMBOK. Modeling these processes and interconnecting them would allow better project control. Thus, associating indicators with processes (risk, cost, time, quality, earned value, etc.) together with predictive simulation would greatly facilitate project management decision-making [START_REF] Otto | Trade-off strategies in engineering design[END_REF]. In our research, our aim is to develop a method and tool capable of guiding project managers and helping them make decisions by simulating, assessing and optimizing different project scenarios, while also enabling early detection of risks and opportunities. To develop this method and tool, we need to be compliant with SE and project management standards. We thus identify criteria by which to evaluate standards according to our research objectives in order to select the most appropriate.

B. Detailed comparison of standards

The SE standard selected had to satisfy several specific criteria. Our needs are listed below:

• We need the standard to cover the entire system life cycle, from conception to retirement.

• With increasing project complexity, V&V (validation and verification) becomes more and more important; the standard should provide a detailed view of the V&V processes.

• The object of our research was to find the best tools for coordinating processes and simulating project progress; as a result, the relationships between processes are key points for the comparison of standards.

From these needs, we derive certain criteria for refining the comparison of standards. The extent of coverage and the level of abstraction criteria have already been discussed. We add three new criteria. The first two are validation and verification, each with their respective level of detail. In order to ensure that the simulation of project progress is reliable, we need to know and model the relationships between the processes clearly. It is therefore necessary to study a third criterion, the degree of internal consistency of each standard, to enable an evaluation of the possibilities of cooperation between the processes. The resulting analysis is shown in Table II. The V&V processes of the EIA-632 are the most detailed and the relationships between the processes are the clearest of the three standards. From Table I and Table II, we conclude that EIA-632 satisfies our needs; it focuses on the enterprisebased system and the level of abstraction leaves the user of the standard sufficient flexibility. It also offers more details about the V&V processes. However, the EIA-632 does not meet all the criteria. For example, it does not completely cover the system life cycle, and it does not consider the tailoring process to deal with the development of system complexity.

C. Our proposal to use a multi-standard approach

Of the standards, EIA-632 seems the most appropriate. However, no standard fully satisfies all the criteria; we therefore study the possibility of extending the EIA-632 by the addition of some elements to better satisfy our criteria We choose IEC-15288 to complete the EIA-638. Table III combines Table I and Table II, and shows the coverage (colored portion) of our criteria by the different standards. We add the maintenance process and the disposal process to EIA-632 to cover the entire system life cycle. Our proposal is thus to choose EIA-632 as the major standard because it satisfies most of our research criteria, but regarding the system life cycle (such as the maintenance and disposal processes), the integration process, the human resource management process and the tailoring process, we propose to complete it with elements from the IEC-15288 standard. The final architecture of systems engineering processes is shown in Figure 4; the processes that are underlined are selected from IEC-15288, the others come from EIA-632. At this stage of the study, we obtain a multi-standard SE reference that satisfies general and specific criteria. However, considering the processes of this reference and their relationships in detail, it is necessary to verify the following:

• That the processes extracted from EIA-632 or IEC-15288 are mutually compatible.

• That the processes extracted from the two standards offer a similar level of abstraction.

• That the processes extracted from IEC-15288 can be subdivided into the 5 groups of the EIA-632 standard.

• That the processes extracted from EIA-632 and IEC-15288 share the same vocabulary and that tasks and activities are not duplicated.

The next section analyzes the dangers inherent in this multi-standard approach and validates our proposal.

D. Discussion of the proposal

We first have to consider the compatibility of processes. As in the EIA-632 standard that there is no process that is identical to any process we selected from the IEC-15288, this eliminates the principal risk of inconsistency. Second, these processes involve only a few activities. When we execute tasks that correspond to the processes from IEC-15288, we only need to execute these processes instead of the tasks in the EIA-632. We conclude that the processes concerned are mutually compatible.

A second problem concerns the abstraction level. Although the abstraction level of the EIA-632 is higher than that of the IEC-15288, the processes from the two standards have the same architecture. Both standards give the definition, purpose, tasks, activities and the outcomes of each process. So the processes from the two standards can be used in the same way.

A third problem is how to classify the processes from the IEC-15288 into the five groups of the EIA-632. As we showed in Figure 4, the integration process, maintenance process and disposal process are clearly in the product realization group, while the tailoring process is in the technical support group.

A fourth problem concerns the definitions used in the three standards. We compared the definitions in the three standards and found that the brief definitions are identical or similar. For example, in the EIA-632, the definition of "process" is "the process is a set of interrelated tasks that, together, transform inputs into outputs"; in the IEC-15288, the definition of " process" is "the process is a set of interrelated or interacting activities which transforms inputs into outputs". Definitions of "process" in both standards have the same meaning.

After analyzing the four risks defined above, we conclude that they present no real danger for the multi-standard approach and can be avoided easily. As a result, the processes from the different standards can work together very well.

Besides, our proposal is not the first multi-standard initiative; many standards exist in multi-standard form. One of the most popular standards is the Systems Engineering Handbook (version 2.0) [START_REF]INCOSE Systems engineering handbook V2.0: A "How to" Guide for all engineers[END_REF]. The purpose of this standard is to provide a set of the key activities during SE; it is in conformance with the EIA-632 but proposes some adaptations to it. It also provides some methods and tools for SE. We did not adopt the SE handbook because, although it meets all the criteria in Table III, it is excessively detailed and lacks flexibility. Another example is the IEEE-1220. Its authors thought that it could be used in conjunction with the IEC-15288 because of the different focus of the standards. The IEEE-1220 describes the development stage of the system life cycle in greater detail, and the IEC-15288 describes all the activities throughout system life cycle. Although the abstraction levels of the two standards are different, the authors of the IEEE-1220 proposed using the more detailed systems engineering process and the management requirements to complete the IEC-15288 [START_REF]ISO/IEC/IEEE Systems and Software Engineering -System Life Cycle Processes[END_REF]. We did not adopt IEEE-1220 either because it is only suggested for use in conjunction with the IEC-15288. The multi-standard approach that we propose for systems engineering has the same logic as the SE handbook, using two standards together, and also gives greater flexibility for development.

V. CONCLUSION Nowadays, developing a system is becoming more and more complex. In order to develop systems quickly and efficiently, it is necessary to implement careful SE management during systems engineering. Many SE standards have been drawn up in recent years; there are many publications of systems engineering management methods like PMBOK. But the lack of consistency and the existence of conflicts between SE standards and SE management make it difficult for project managers and project teams to implement efficient project management. Our research objective was to improve the coordination of systems engineering processes with systems engineering management, in order to help project leaders choose the most efficient and coherent option for best achieving their targets. Considering this objective, the processes we consider must cover the entire system life cycle at an abstraction level that leaves some flexibility for the project team. For project progress to be simulated correctly, the validation and verification processes should be included. It is also important to facilitate relationships between the processes to simplify the simulation of project progress.

After a brief introduction of the most important SE standards, this paper analyzed and compared the three most important. EIA-632 appeared to be the most suitable standard for our purposes. It met most of the criteria, but because of the scale of most systems, it was necessary to use processes from other standards to complete it. We therefore proposed to use processes from the ISO/IEC-15288. After integrating them with the EIA-632, we obtained a multi-standard reference that can cover the entire system life cycle, allows more flexibility and expandability for systems engineering, focuses more on validation and verification and defines all the relationships between processes. This multi-standard is thus well adapted to guide complex systems engineering projects.

Fig. 1 .

 1 Fig. 1. Structure of the ANSI/EIA-632:1998 standard

Fig. 2 .

 2 Fig. 2. Structure of the ISO/IEC-15288:2008 standard

Fig. 3 .

 3 Fig. 3. Structure of the IEEE-1220:2005 standard

Fig. 4 .

 4 Fig. 4. The final systems engineering processes

TABLE I

 I

		.	SYSTEMS ENGINEERING STANDARD DIFFERENCES [4]
		ANSI/EIA-632:1998	ISO/IEC-15288:2008	IEEE-1220:2005
		• Assessment of opportunities
		• Investment decision
	System life	• System concept development
	cycle	• Subsystem design and pre-deployment
		• Development, operations, support and
		disposal

TABLE II .

 II

		ANALYSIS OF STANDARDS ACCORDING TO THE THREE NEW CRITERIA
		ANSI/EIA-632:1998	ISO 15288:2008	IEEE 1220:2005
	Validation	Gives more details about validation: requirement validation; solution representations, end products validation	Requirement validation	End product validation
	Verification	Gives more details about verification: design solution verification; end product verification; enabling product readiness	Function verification	Design verification
	Internal consistency	Highest, gives the relationship between the processes, activities	Higher than IEEE-1220:2005	Lowest

TABLE III .

 III

		FULL COMPARISON OF STANDARDS
		ANSI/EIA-632:1998	ISO/IEC-15288:2008	IEEE-1220:2005
			Defines 3 concept groups and 4	Defines 14 general requirements for
		Defines 5 process groups, a total of 33 requirements for 13	process groups, 25 system life	developing a total system, gives 8
	Scope of standard	processes, gives tasks and outcomes for each requirement,	cycle processes, gives the	sub processes for one systems
		gives some application context and key concepts	purpose, tasks and outcomes	engineering process, gives the tasks
			for each process	and activities for each sub process
	System life cycle	Assessment of opportunities Investment decision System concept development Subsystem design and pre-deployment Development, operations, support and disposal	Conception Development Production Utilization Support Retirement	System definition Preliminary design Detailed design FAIT Production Support
	Level of detail of the processes	Higher level than ISO/IEC-15288, lower than IEEE-1220	Lowest level	Highest level
	Focal point	Enterprise-based systems	Product-oriented systems	The engineering activities necessary to guide product development
	Validation	Gives more details about validation: requirement validation; solution representations, end product validation	Requirement validation	End product validation
	Verification	Gives more details about verification: design solution and end product verification; enabling product readiness	Function verification	Design verification
	Internal consistency	Highest, gives the relationship between the processes, activities	Higher than IEEE-1220	Lowest


Vatsal Pant
email: vatsal.pant@isae.fr

Jean-Charles Chaudemar
email: jean-charles.chaudemar@isae.frhamid.demmou@laas.fr

Hamid Demmou

"The rise of connected systems in industry and services" Safety Analysis of Pilot-System Interaction

Keywords: STAMP, STPA, MBSE, MBSA, Process Model, Flight Control, Safety

This paper presents on-going work in the scope of development of a new methodology of safety analysis taking into account pilot's behavior. The initial part of the research deals with understanding pilot error and to model his behavior against required tasks. The paper presents the methodology and the tool developed for this purpose.

INTRODUCTION

Flight travel has become safer and safer over the years thanks to the various state-of-the-art technologies used in design and development of the aircraft (Clinton V. Oster Jr. 2013). But, the human error as cause of accident still remains at the same ratio. It was shown in a research by 1 the cause of human error due to bad decision making amounts to around 25 percent [START_REF] Wiegmann | A human error analysis of commercial aviation accidents using the human factors analysis and classification system (hfacs)[END_REF]. Researchers are trying to study what more (or in some caseless) information should be given to the pilot in order to improve his decision making and reduce any chances of error. Our research has the same objective, i.e, to provide the pilot with information about what might go wrong based on the current situation he is in. For example, based on the descend trend at a particular instant, an automated analysis is performed and then the pilot is informed of the possible hazardous situation he might enter into. In this process, the time is of the utmost importance in order to perform a possible corrective maneuver. One of our objectives in this study is to develop a safety analysis method that takes into account pilot's task behavior. To do this a new hazard analysis technique developed in MIT, USA called STAMP-STPA has been used [START_REF] Leveson | Engineering a Safer World: Systems Thinking Applied to Safety[END_REF].

The paper presents this new hazard analysis process in the second section. Third section explains the methodology used to meet that objective. Fourth sections details about modeling the pilot task behavior, moving on to the fifth section where the use of ADS-B data in our project has been described. The following section introduces the tool developed for carrying out the aforementioned analysis. Some results and conclusions are presented at the end.

STAMP and STPA

This section defines the STAMP process model, the hazard analysis process based on STAMP called STPA, and a brief introduction to use STPA.

System Theoretic Accident Modeling Processes (STAMP) is a methodology used to model a system and/or a process. It is based on the concepts of Systems Engineering and Control Theory. The modeling is done on the base of functional structure rather than the physical component structure. The entire process is classified in different level of complexities starting from the most complex at the top and then going down to the least complex at the bottom. This complexity corresponds to the functions performed at each level. Each level has a controller and a process as shown in Figure 1. Each controller gives some control actions as input to the process and receives feedback from the process. ( • Define Accidents and Hazards (associated with these accidents) and obtain loss of control that can lead to a hazardous state

• Identify how these unsafe control actions could occur in the control structure.

Unsafe Control Actions (UCA) are the commands given by the controller to the process that can result in a hazardous situation. UCA is defined as:

Context + ControlAction + Hazard
Here, Context is defined as the scenario or condition or constraint that helps us in assigning safe or unsafe nature to a control action [START_REF] Thomas | Extending And Automating A Systems-Theoretic Hazard Analysis For Requirements Generation And Analysis[END_REF]. For example, one can imagine that the pilot lowers the landing gear, this is a control action but it becomes an unsafe control action if it is lowered at a high speed and at a high altitude, as it increases the drag on the aircraft and it becomes even more critical if there is a critical situation like fuel starvation. This might result in stall. Hence it is very important to carefully consider the context.

According to STPA there are four types of possible unsafe control actions:

• Providing a control action will cause a hazard. In this case, the control action may be tagged as "inappropriate".

• Not providing a control action will cause a hazard. This is the absence of a required control action.

• Providing it too early/too late will cause a hazard. The focus is on the time at which a control action is provided.

• Providing it for too long or stopping it too soon will cause a hazard (this is more applicable when the input is continuous). The focus is on the duration of the control action.

Given these STAMP and STPA concepts, our study relates to an original approach enabling to extend STPA analysis for on-line safety analysis.

PROPOSED METHODOLOGY

This section defines the approach used in order to integrate the concept of unsafe control actions with safety analysis.

As aforementioned, the UCA concept becomes a central component of our methodology, which requires to formalize it. For that, a formal tabular specification [START_REF] Russo | An Abductive Approach for Handling Inconsistencies in SCR Specifications[END_REF] is used to define the unsafe control action uca ij , such as for any i, j :

uca ij = < C i , U C j , u ij >
where:

• C represents the Context, i.e. the current state variables characterizing the system behavior with its given environment; then, C i is the ith element of this list of context.

• U C stands for the type of the control action as defined in STAMP; we assume there are 6 types as described below.

• u corresponds to the textual description of the hazard of the concerned unsafe control action; i, j is for the posiion of the cell in the table.

An illustration of STPA table structure is shown in table 1, where n > m. On the other hand, the types of UCA 3 and 4 are split hereafter, since their description states two distinct features. Therefore, the type rearrangement is given as follows:

UC 1 UC 2 UC 3 UC 4 C 1 u 11 u 12 u 13 u 14 . . . . . C n u n1 u n2 u n3 u n4 . . . . . C m u m1 u m2 u m3 u m4
MOSIM18 -June 27-29, 2018 -Toulouse -France

• U C 1 : for providing ca which is inappropriate, noted uca(t0 = ok, td = ok).

• U C 2 : for absence of ca, noted ca(t0 = ∞, td = ok).

• U C 3 : for providing ca too early, noted ca(t0 = -, td = ok).

• U C 4 : for providingca too late, noted ca(t0 = +, td = ok).

• U C 5 : for stopping ca too soon, noted ca(t0 = ok, td = -).

• U C 6 : for a long duration of ca, noted ca(t0 = ok, td = +).

Contrary to the UCA types, the Context relies on actual data extracting from aircraft actual behavior. To be relevant, these data are given by actual records of several flights, in approach phase for our study case.

The process using this data base is described hereafter.

Figure 2 explains the proecess of our study. Our proposed methodology deals with studying a very critical phase of a flight, e.g. approach phase. This methodology consists of several steps depicted as follows:

Step1 : To build an initial STPA table in order to obtain control actions.

Step2 : To collect data in order to understand how pilot actually perform successful approaches. To do this, ADS-B was used.

Step3 : To develop and use a tool that takes current position of the aircraft and improves STPA analysis in order to list unsafe control actions that a pilot might give.

As far as the prediction of UCA is concerned, STPA table and the ADS-B data base are necessary for the tool to be developed, however the performance of the prediction would actually be improved if we are able to add a model of pilot tasks, which reduces the number of possible irrelevant unsafe control actions. For multiple failure, we assume for instance that an U CA 4 can not be immediately followed by an U CA 3 , thus, the time analysis is taken into account [START_REF] Bruggemann | Analysing the reliability of multi UAV operations[END_REF].

The next section shows an ideal pilot task model that we would like to generate automatically from the STPA table, ADS-B and official procedures.

MODELLING PILOT TASK BE-HAVIOUR

The first part of the research deals with modeling the behavior of pilot in response to tasks that he/she has to perform. To be able to do that the available manuscripts that aid pilot in training and subsequently performing certain tasks, e.g., FCTM, FCOM, and SOPs are used. (To be noted that these are not the official documents from aircraft manufacturers but the ones available online. ref: www.airbusdriver.net) Since our study is based on one of the most critical phase of flight, i.e., approach and landing, we will, for the moment, look only at those actions that will be performed during this phase. Figure 3 gives an idea of the task performed during approach phase. These tasks are to be performed by the pilots at certain altitude, speed and at required distance from the Touch Down Zone. It can be seen that these tasks correspond to some actions that the pilots have to perform. Each time they perform these tasks they need to make certain decisions based on current state of the aircraft, environmental conditions and other external factors (like Air Traffic Controllers instruc-MOSIM18 -June 27-29, 2018 -Toulouse -France tions). We tried to study the hazardous conditions that might exist and based on it we constructed a flowchart (Figure 4). This flowchart enables us to improve STPA analysis by providing important control actions. It also gives some idea on some decisions that the pilots make based on their mental model (expereince, fatigue, stress level, etc.). These are different from the actions he performs based on the prescribed procedures. We call these two type of decisions as procedure based decisions (represented in Figure 4 Based on this model we obtain control actions that we use next. The next section gets an insight into the of ADS-B for actual pilot behavior.

ADS-B DATA

ADS-B stands for Automated Dependent Surveillance -Broadcast, it is a technology that helps an aircraft obtain its position based on satellite navigation and broadcasts it. This allows ground based receivers to track an aircraft. This is very useful for ATC and other aircraft to know exact position of other aircraft in order to maintain safe separation. The ADS-B data packet contain information about the track, ground speed, call-sign (it is a type of aircraft identifier) and position of the aircraft. ADS-B data help on-line flight tracking platforms to track air traffic in real time.

We have used the data from various approach patterns of Airbus A320 aircraft in Toulouse, Blagnac airport (ICAO: LFBO). We extract data that enables us to understand how diferent pilots react in certain situations while performing the required task. This was done by studying how the speed and altitude changes with time (Figure 5). Studying these graphs over a wide range of data will provide us an understanding of the normal trends of altitude and speed change for successful landings that might help us define our safety margin.

Another interesting plot that was extracted was Altitude vs Speed. This was particularly interesting as this eliminated time variable. Since not all pilot perform similar actions at same time, it is interesting to find a way to find a common performance graph. It is normal to have an approach curve like this, it should not be confused with unstable flight as the MOSIM18 -June 27-29, 2018 -Toulouse -France curve doesn't represent the actual position of the aircraft. It shows the trends in altitude and speed. Some sudden spikes and drops in the curves arise mainly due to missing data or some changes that occur due to operational reasons like extension of landing gears, etc.

INTRODUCTION TO THE TOOL

The authors decided to develop a tool that can automatically perform the analysis. MATLAB based GUIDE (Graphical User Interface Development Environment) is used to build this tool. The tool takes ADS-B data as the input and predicts unsafe control actions. It also plots an altitude vs speed diagram of the approach in order to compare it to safe approach patterns. Figure 7 shows the layout of the tool. It has a mode selection switch that decides whether data will be taken automatically or must be entered manually. There is an input box that allows data to be entered manually. The output box presents results from the analysis. And the nominal performance curve plots the fitted curve based on the data points that are input. The tool carries out following tasks.

• Taking position, speed and heading values from ADS-B receiver and importing it in a .csv file (done in "Automatic" mode). This can also be input manually by selecting "Manual" from the Mode Selection Switch.

• Plot a nominal approach Altitude vs. Speed curve for a particular aircraft type and a particular airport. It is done in the "Nominal Performance Curve".

• Based on the values of Altitude and Speed assume which step of procedure the pilot will perform next. Compare the current action to actions in future and list down possible unsafe control actions in the output box.

In order to performance the analysis following steps are performed:

• Define the nominal approach curve based on the values obtained from ADS-B data.

• Select a point for which we want to study the scenario, or perform our analysis. This is crucial as the aircraft is constantly moving instead of performing the analysis every second it might be interesting to do it over a time zone for which the conditions remain same, and change it over to the next zone as soon as it passes to the next scenario.

• We use data from the aircraft to obtain a safety margin. This is obtained by plotting all the safe landings over a period of time and then based on extreme points making a safe envelope.

• Calculate the distance of our selected point from the safety margin.

• Based on this distance define the context for unsafe control action (e.g., Low/high speed (if the speed difference is too much) and same for altitude).

It is done by obtaining the factor (altitude or speed) that is farthest from the safe margin and use that as "critical" because it will be difficult to achieve.

• Based on the context and current position populate the list of unsafe control action on the tool.

RESULTS

Once all the Unsafe Control Actions were defined, they were entered in the tool for analysis of an aircraft in real time. The tool provides us with results in the output box in uca ij = < C i , U C j , u ij > format. For example in Figure 8, based on current altitude and speed performing the next control action will result in stall due to increase drag. Here the context is low speed and the corresponding hazard is Stall.

CONCLUSION AND FUTURE SCOPE

This tool was necessary to better visualize the study for ourselves and to be able to distribute as a standalone application to Engineers and pilots to collect data and have their feedback. As mentioned the tool is in the preliminary stage although it can perform some analysis at this level too. A mid-term progress would be to perform some real time tests on simulator to evaluate the performance of the tool and to improve it. At present a safety margin has been obtained and the tool can base its analysis on this safety margin. However, as part of current work, machine learning is being introduced in order to have a safety envelope that is more accurate. Machine Learning/Neural Networks can also be implemented to automatically select a context based on the position of the aircraft, pilot's previous actions, and the environment in real time (wind, etc..). This tool will also be proposed to a discussion with pilot's and have their feedback. This is also very important in order to validate the tool.

  Figure 2 -Methodology

Figure

  Figure 3 -Approach Procedure

Figure 5 -

 5 Figure 5 -Altitude and Speed vs Time

Figure 6 -

 6 Figure 6 -Altitude vs Speed

Figure 7 -

 7 Figure 7 -Screenshot of the Tool

Figure 8 -

 8 Figure 8 -An output on the Tool

  [START_REF] Thomas | Stamp/stpa beginner introduction[END_REF]) June 27-29, 2018 -Toulouse -France of control since the focus is on early functional architecture instead of physical one. The basic ideology is that there have been incidents in the past where neither components failed nor humans made error yet accidents occured (Nancy[START_REF] Leveson | Applying stamp in accident analysis[END_REF].

	Another useful concept in safety is the hazardous con-
	dition depicting the result of a failure in the STAMP
	framework.
	Moreover, STAMP offers a collection of processes, in-
	cluding a System Theoretic Process Analysis (STPA),
	which is of interest for our study. STPA is a top-
	down method that makes use of a control structure.
	It is performed in following two steps (Leveson &
	Thomas 2013) :
	Controller
	Process Model
	Control Actions	Feedback
	Controlled Process

Figure 1 -Control based STAMP model According to this modeling, an associated definition of failure is proposed, thus failure is defined as loss MOSIM18 -

Table 1 -

 1 Unsafe Control Actions tableOn the one hand, this UCA table structure implicitly reveals a time characteristic for a control action (noted ca, later on). Let be t0 the starting time whose discrete value belongs to ok, +, -, ∞, ok is the appropriate time, + too late time, -too early, and ∞ for absence of ca . Similarly, td the duration whose value belongs to ok, +, -, ok is the appropriate duration, + too long, and -too short.

ACKNOWLEDGMENTS

The ongoing research is being funded by Dassault Aviation. The project is under the ISAE-SUPAERO and Dassault Aviation chaire.


Romaric Guillerm
email: guillerm@laas.fr

Hamid Demmou
email: demmou@laas.fr

Alexandre Nkesta
email: nkesta@laas.fr

Jean-Jacques Carrillo

Co-Simulation of Complex Multi-Physics Systems Aeronautical example

Keywords: Co-simulation, complex system, multi-physic system, electric distribution

Co-simulation is part of the current techniques to simulate multi-physics systems, which has a number of advantages compared to a complete simulation within the same multi-physics simulator. The principle is to connect existing dedicated simulators and to run in parallel these simulators allowing them to exchange data. A concrete example, based on the modeling of a new system of electric power distribution, illustrates this approach.

I. INTRODUCTION

Complex systems associate many components and several phenomena of different natures [START_REF] Bar-Yam | Dynamics of Complex Systems[END_REF]. They involve different domain or scientific disciplines, each of which deals with one physical aspect of the system. For example, these physical aspects correspond to the science of solid mechanic, fluid mechanic, chemistry, electromagnetism, thermal, automation or computing. Meanwhile, since several years the cost and time constraints imposed by the market on industrial projects induce a very restrictive prototyping. Less expensive and faster to implement, computer simulations progressively replaces this step. Many software tools exist for deep analysis and simulations in every scientific domain. However, all the existing underlying interactions between phenomena make essential a simultaneous and common simulation of all fields. Various solutions exist today, including tools for multi-physics simulation [START_REF] Istardi | Induction Heating Process Design Using COMSOL Multiphysics Software[END_REF]. Their principle is to integrate within a single software all phenomena, all possible physics. This approach provides excellent results. However, for our point of view it presents a number of disadvantages:

• Tools become very heavy because each tool has to deal with all the existing physics in the systems. • They are not ergonomically suited to the working mode of a specific domain, because they have one common interface that integrates all the aspects. • They force engineers to use new working tools, while they have specific tools well adapted to their own respective areas. Addressing the problem in a different way, a second approach is possible: the co-simulation [START_REF] Schmerler | A backplane approach for cosimulation in high-level system specification environments[END_REF] [START_REF] Glass | A co-simulation approach for system-level analysis of embedded control systems[END_REF], which allow engineers to keep their own specific simulation tools provided with new interfaces -software meaning (not graphical) -allowing them to communicate. The communication between different simulators allows to simulate the different models of the system, potentially related to different physics, as parts of the entire system. This approach is referred to co-simulation.

After this short introduction, the objective of this paper is to introduce the approach of co-simulation, followed by the presentation of the general principle in the second part. Then, a number of tools that we use are presented in the third part. The fourth part is devoted to the presentation of an industrial example with an application of co-simulation. It is about a new electrical power distribution system for aircrafts developed by the Edison Ways Compagny. The fifth and final section concludes the paper and presents some possible perspectives.

II. PRINCIPLE OF CO-SIMULATION

Co-Simulation -Definition

The first objective of the co-simulation was to do a mixed simulation between software and hardware systems [START_REF] Yoo | Hardware/software cosimulation from interface perspective[END_REF]. Now it is possible to simulate systems increasingly sophisticated and composed of different subsystems of various natures (electrical, mechanical, hydraulic, ...). Used during the design, the co-simulation allows the validation of the complete system before its implementation, helping to correct design errors earlier.

From a global point of view, the principle of the cosimulation is the parallel execution of multiple simulators. Each simulator executes a system model established in a language specific to the concerned area. Then, all the models of the different simulators form the complete modeling of the system.

Communication between models

The co-simulation requires therefore an exchange of information between different simulators. To do this, a dedicated standard exists: the HLA (High Level Architecture) [START_REF] Dahmann | The Department of Defense High Level Architecture[END_REF]).

The HLA is a standard of interoperability for distributed simulation. It formalises the architecture and rules of interaction and it is based around a RTI (Run-Time Infrastructure). However, this solution is not the one that we have adopted.

In our work, we prefer to use the principle of co-simulation with data exchanges through a bus that is provided by a specialized tool: Cosimate, presented below. An illustration of this principle is shown in Figure 1.

Synchronization modes

Several methods of synchronization between models are possible for the co-simulation. Mainly, we distinguish the two following modes: event driven or synchronous.

The principle of the event driven mode is asynchronous communication between models. Each model can have its own clock, independent of those of the other models. Messages are sent or read by each model only when this one decide to do so. The overall behaviour of the co-simulation is then provided by the implemented communication protocols and their consistencies.

With the synchronous mode, the clocks of the different simulators evolve simultaneously: they are synchronized. Every data is exchanged at each co-simulation step. This mode is particularly suitable for co-simulations implementing various physical phenomena evolving in different simulators and possibly coupled. It is this second method that we implement in our case study.

III. TOOLS PRESENTATION

This part presents the different tools, simulators or languages that we will use in the fourth part to treat an industrial example. The first one is essential to our approach: it is Cosimate.

The bandmaster: Cosimate

Cosimate is a software tool developed by the Chiastek Compagny, allowing the co-simulation of a model set by establishing communications between several tool simulators or languages [START_REF] Colenbrander | Co-design and Implementation of the H.264/AVC Motion Estimation Algorithm Using Cosimulation[END_REF] [START_REF] Mitts | Using a Cosimulation Framework to Enable Software-in-the-Loop Powertrain System Development[END_REF]). These simulators are either on a single machine or multiple machines distributed across a local or global network. The current version of Cosimate (2014.02-v7.0.0) supports many simulators (including Simulink and OpenModelica) and several languages (including C and Java).

As stated above, Cosimate therefore adopts the principle of communication by exchanging data through a co-simulation bus. All the models of the system which is desired to achieve co-simulation will be connected to this bus (see Figure 1).

OpenModelica

OpenModelica is an open-source tool for modeling and simulation, developed by the OSMC (Open Source Modelica Consortium). The models created with this tool are defined into Modelica language (hence the name of the tool), which describes a system as a set of equations. It allows modeling of complex systems, including mechanical, electrical, hydraulic or thermal. OpenModelica can itself be considered as a multi-physics simulator.

In our case, we use OpenModelica for its ability to model an electrical system.

Simulink and LabView

In order to control and view system information during the simulation, we initially implement a HMI (Human-Machine Interface) with LabView. This tool from National Instruments enables the creation or the quick prototyping of graphical user interfaces.

However, this tool is not directly supported by Cosimate. To use it with our co-simulation based around Cosimate, we used the feasible connections between:

• Simulink and LabView, through the SIT (Simulation Interface Toolkit) which is an add-on provided by National Instruments. • Cosimate and Simulink.

C language

The C language is an imperative programming language widely used, especially for programming microcontrollers. We use the C in our case study for system management and control software programs precisly supposed to be implemented on microcontrollers.

Java language

The Java language is inspired by the C++ object oriented language. We used it only for the implementation of a more accomplished HMI dedicated to the visualization and control of the studied system, using the Swing standard library.

VI. INDUSTRIAL EXAMPLE: NEW ELECTRICAL POWER DISTRIBUTION SYSTEM 1. Presentation of the System

We illustrate the approach of co-simulation with the use of various tools/simulators on a new electric power distribution system for airliners. This system completely rethink the architecture of the electrical distribution system and offers an innovative, lighter, more economical, safer, and more maintainable solution. Many patents protect this new concept named "Captain". They are held by Jean-Jacques Carrillo, founder of the Edison Ways Compagny.

Note: For privacy reasons, this article will not present in detail all the different parts of the system. However, it presents a general view of the functional principle, enough to understand the main features of the system.

The Figure 2a shows the traditional architecture of the electrical system of airliners.

The Figure 2b exhibits the new system architecture using the "Captain" network. The general principle is to pool the electrical distribution in multiwire networks sized relatively to the sources (ie the generators). The primary distribution systems disappear and leave space to dispatchers, located in the center of the aircraft, and a set of secondary distribution systems scattered along networks. The largest gain for the aeronautical industry is undoubtedly on mass. Indeed, the use of this system allows a gain of more than 60% of the wiring mass, which represent a relief of more than 2 tonnes for an aircraft like the A380.

The different models in interaction

In our case study, the configuration of the system that we chose is composed of 3 generators (twin engine configuration with APU) and 3 networks. Two networks are oriented to the front of the aircraft and are connected to two secondary distribution systems each. The third network is localized in the back of the aircraft and is connected to three secondary distribution systems. The figure 4 provides a representation of this configuration.

We connect 10 models to achieve a co-simulation of this system:

• 1 electrical model, made in OpenModelica,

• 1 C code for the management and control software of the dispatchers, • 7 similar C codes for the management and control software of the secondary distribution systems (1 code for each one) • 1 Simulink gateway linked to one LabView interface, or -depending on the choice of the GUI -1 Java tool, for the user interface. The figure 1 shows this set of models connected to the Cosimate bus in its Java tool version for the choice of the HMI.

a. Electrical model

The highest level of the electrical model is visible in figure 5. This model matches to the configuration fixed for our study ; it models all the electrical components and the connections from the generators to the loads, through dispatchers, multiwire networks and secondary distribution system.

Figure 5: Electrical model Considering the number of components of the system, the compositional aspect of the Modelica language has been widely praised here and used to define classes of objects: slices of circuit breakers, secondary distribution system, subdispatchers, dispatchers, etc.

Towards the co-simulation bus, data exchanged are:

• For those sent on the bus: the values of currents or voltages, mainly, • For those from the bus: the states of the circuit breakers in order to control them, electrical parameters, or information relating to faults injected into the system. The level of abstraction chosen led us to encode a single management software to govern all of the dispatchers. The role of this program is mainly to monitor the loads of generators and networks. If an overload is detected, several strategies have been defined to return to an acceptable situation. This potentially involves dynamic reallocations or unballastings of loads that are not essential a safe flight.

b. Management and control software of the dispatchers

Details of these strategies are not described in this article, both for reasons of pages limitation and confidentiality.

This management software operates on data from the electrical model, passing through the co-simulation bus.

Then, it makes decisions that determine the state of the circuit breakers at the dispatchers level or control orders sent to the secondary distribution systems.

c. Management and control software of the secondary distribution system

Each secondary distribution system is provided with a management software. This program is designed to manage the connection or disconnection of the loads associated to the secondary distribution system. It works autonomously but also receives orders from the management software of the dispatchers that must be treated. In normal operation, its role is mainly to balance consumption between the two subnetworks to which it is attached.

To work, this software uses also values provided by the electrical model transmitted trough the co-simulation bus, in addition to the orders from the software of the dispatchers that it receives as input. The decisions concern the status of the circuit breakers at the secondary distribution system level.

d. Human-Machine Interface (HMI)

As previously announced, two versions of the HMI were implemented.

The first one was created with the LabView software, dedicated specially to the fast development of user interface (see figure 6). The advantage here is the extremely short time and ease of development with such tool.

However, disadvantages of this solution are:

• The fact that LabView is a commercial tool,

• The need to use Matlab/Simulink -another commercial tool -to connect the interface to the co-simulation bus of Cosimate, • The opportunities in terms of HMI and ergonomics, less widespread and sophisticated than with a pure programming language.

These disadvantages have led us to perform a second interface in Java. Nevertheless, the interest of using LabView in the early stages of the project was still not negligible, as it allowed to have very quickly a functional interface that was used for the first versions of the simulator. The work effort was then turned to the electrical modeling and the algorithms implemented by the different software. Therefore, the second interface has been implemented entirely in Java. It includes many more features, for example the ability to define in advance scenarios (including both dated events or random events associated with probability distribution), to save them, or to execute them. This Java interface also provides an animated and interactive aircraft view, which brings a better understanding of the system and its operation. The figure 7 shows the main view of this interface, under the "aircraft" tab.

Figure 7: HMI implemented in Java

Co-Simulation and Results

Different scenarios have already been tested using this simulator around the co-simulation bus of Cosimate.

a. Running one scenario

To start a co-simulation with Cosimate, the procedure is as follows:

• Open the project in Cosimate (see figure 1), and start the co-simulation, • Then, Cosimate will, for each model and based on the project parameters, run models automatically or prompt the user to do so. In this step, it is therefore to run models on Cosimate requests.

In our case study, for example, we set the co-simulation so that the various C codes start automatically. It remains the responsibility of the user to run the simulation with OpenModelica and under the Java HMI when requested by Cosimate.

In order to run a predefined scenario, simply select it before in our Java HMI. This scenario will be used for the cosimulation, without preventing a possible interaction of the user who can inject new events on the fly.

b. Results analysis

Once the co-simulation is finished, many results can be analyzed:

• Traces of the Cosimate tool,

• Data of the simulators,

• Log files of the codes.

For example, the OpenModelica simulator allows to plot the curves of the evolution over time of any parameter of the model, like the current in a wire of a network (figure 8) or the one delivered by a generator (figure 9). The management software have been coded to keep track of their states and their decisions in files. These traces are very useful to test and validate the developed and implemented strategies, and also to validate the functional aspects of the new architecture of the electrical distribution system inside an aircraft.

V. CONCLUSION

The objective of this article was to present a framework for the co-simulation of complex multi-physic systems. The principle here is the use of a co-simulation bus, using the Cosimate tool, alternative to an HLA-based approaches. The use of this approach in an aeronautical project showed its feasibility and interest. The models are made with specific tools in the preferred environments of the engineers. All models aggregated around the co-simulation bus then allow a co-simulation to validate and verify the system. Moreover, it is possible to refine and reduce the level of abstraction of some models without jeopardizing the whole simulator and architecture.

Figure 1 :

 1 Figure 1: Co-simulation bus connecting different models (Cosimate view)

Figure 2a :

 2a Figure 2a: Traditional architecture

Figure 3 :

 3 Figure 3: Multiwire network with dynamic allocation

Figure 4 :

 4 Figure 4: Electrical system configuration

Figure 6 :

 6 Figure 6: HMI implemented with LabView

Figure 8 :

 8 Figure 8 : Currents in the subnetworks


Mathieu Guérin

Access to Forest Resources and Effectiveness of Protected Areas in Malaysia: A Historical Perspective on the National Park and the Krau Reserve since the Colonial Era

Seed dispersal is an important mechanism in the dynamics of ecosystems. In order to understand it clearly, many researchers in the tropics favour places where human interference is minimal to conduct their studies, like protected areas [slide 2]. In the 20 th century, protected areas have become a major tool for the conservation of ecosystems. However not all of them have been successful. A number of factors affecting their efficiency have been identified: location, size, boundaries and buffers, laws and regulations enforcement, involvement of local communities [START_REF] Woodley | Managing Protected Areas for Biological Diversity and Ecosystem functions[END_REF], Laurance & al. 2012[START_REF] Bruner | Effectiveness of Parks in Protecting Tropical Biodiversity[END_REF]).

This paper looks on how the context and processes of the creation of two protected areas during the colonial era in Malaysia had an impact on the protection of the tropical forest ecosystems they harbour during the last 90 years.

As a historical study, this survey is mostly based on the critical analysis of historical sources [slide 3]. Like any Western bureaucracy, the British administration in Malaya filled a vast amount of paperwork, a small portion of which is dealing with the establishment of protected areas in the colony. Much has been lost when the Game Department office was destroyed during World War II. However, what remains allow us to understand the history of the conservation movement in Malaysia (Kathirithamby--Wells 2005).

Looking at the history of reserves and parks only through the colonial archives would give us a biased perspective: that of the British. Fortunately, British Malaya was not a colony but a series of protectorates. The local states, the sultanates, continued to operate alongside the British colonial administration, and some of the correspondence of the sultans with their subjects or the British made its way to the National Archives of Malaysia. Through these letters, the views of the Sultan but also of their subjects, the commoners, on the wildlife reserves emerge.

Besides, enquiries have been conducted by British members of the Malayan Civil Service who met the local communities that were affected by the proposed protected areas. These British administrators wrote reports that presented the views of the people who they met. By combining all these sources we can have a pretty clear understanding on the processes that led to the creation of the two largest protected areas in British Malaya and their management: the Krau Game Reserve, now Krau Wildlife reserve, and the Gunung Tahan Game Reserve established respectively in 1923 and in 1926 in Pahang. The latter was eventually incorporated into the King George V National Park in 1939, which became Taman Negara after Independence. The files of the Game Department, then Department of Wildlife and National Parks, allow us a glimpse on their history until today.

When in the early 20th century, conservation of the wildlife of the Empire became a concern for the British government and the Society for the Preservation of the Wild Fauna of the Empire, steps were taken in Malaya (MacKenzie 1988). Laws were drafted to protect certain species and a Game Department was set up. The main protagonist of this conservation policy was Theodore Rathbone Hubback [slide 4]. A planter and a big game hunter, Hubback was involved in the drafting of the 1921 ordinance on the protection of the fauna of Malaya. Then in 1930, he was commissioned by the King and the sultans to lead a Commission on the Wildlife of Malaya. Subsequently he became the first Chief Game Warden of Malaya. Hubback has been instrumental in the creation of the Krau Reserve and the National Park [slide 5].

Archives show that mainly two categories of people were using these forests before they were gazetted for conservation purposes. First were the Malays living at the border of the park and the reserve. They collected Non--Timber Forest Products (NTFPs), especially rubber, like that of jelutong trees, cut trees for timber, hunted, fished, used meadows as grazing land for their cattle and buffaloes. Some villages also had graveyards within the proposed area of the National Park and they used pathways to cross the forest to go to Terengganu or Kelantan. Second were Aboriginal groups of Forest people who were actually living in the forest. In Krau, the Che Wong were swidden cultivators, while in the National Park the Batek were hunter-gatherers. All of them relied on NTFPs for cash or barter.

Hubback's projects were based on the "Yellowstone model" that implies to suppress all permanent human presence in the park [START_REF] Wuerthner | Yellowstone as Model for the World[END_REF][START_REF] Reiger | American Sportsmen and the Origins of Conservation[END_REF]. In fact, Hubback turned towards conservation after a hunting trip in Alaska where he met with American hunters some of whom were proponents of wildlife protection [START_REF] Barlow | Before our Foundation. A Contribution towards a History of MNS[END_REF]. The Yellowstone model that Hubback wanted to implement in Malaya affected the local populations' rights on forest use. Hubback and the British who supported the wildlife reserves saw them as sanctuaries were human presence, notably that of the natives, was undesirable. This happened at a time when land access became an issue in the peninsula, because of demographic growth and development of cash crop plantations on the West coast.

Sources show that the people affected have been able to change the rules that Hubback and his supporters wanted to enforce. They petitioned their true rulers, the Sultans [slide 6]. The Sultans, especially Sultan Abu Bakar of Pahang, and some British officials then supported the claims of the Malay villagers and of the Batek and Che Wong forest people (Guérin 2017b).

Far from being colonial diktats, the gazetting and regulation of Krau and the National Park was the result of intense negotiations between different parties within the colonial administration, the local inhabitants, the Sultans and their courts that lasted nearly four years in the case of the National Park. Proponents of the preservation of wildlife were forced to make concessions.

The Batek and some Che Wong groups living in the Park and the Krau reserve were allowed to stay and continue their way of living [slide 7]. In the eyes of all British, the presence of the Che Wong and the Batek could easily be tolerated. They were labelled as Sakais, a derogative term, and considered as wild beings, savages. Hubback once wrote that Krau was "The most valuable Reserve for seladang in the whole of Malaya, and a most important sanctuary for all sorts of wild life, including Sakai" (Wild Life Commission of Malaya 1932). They belonged to the world that the British wanted to preserve. They were just asked to give up hunting species that the British wanted to protect the most like seladang, the local name for bos gaurus, or some bird species, like argus pheasant, and to report any poaching activity in the protected areas.

After having been evicted and forced to abandon any activity in the park and the reserve, the Malays of the Tembeling area were allowed a few privileges. They were permitted to travel through the National Park with the limitation that they could not carry any weapon, which actually could be a problem because of tigers and the fear they inspired. They could also collect NTFPs for their personal use but not for sale, to fall trees to build their houses if no other resources were available outside the park, and to collect fruits, knowing that they had planted many of the fruit trees.

Since the time Krau and the National Park were established, the means of the Game Department to monitor the park and the reserves under its jurisdiction have been, by far, inadequate both in terms of finance and staff (Guérin 2017a). However, the Krau Reserve and the National Park have proven quite efficient in protecting the ecosystems [slide 8]. They have not been seriously affected by World War II, despite the complete dismantling of the Game Department, or even by the years of the guerilla war during the state of emergency between 1948 and 1960.

Size and rights of the local communities that were decided when the protected areas were set up, seem to have been important factors of effectiveness. The few assessments that have been conducted tend to present them as high value conservation sites. Rhinoceroses have disappeared from the National Park, but it still harbours some of the flag species of conservation like gaur or tiger. The situation in Krau is a bit more elusive [START_REF] Aiken | Peninsular Malaysia's Protected Areas' Coverage, 1903--92: Creation, Rescission, Excision, and Intrusion[END_REF][START_REF] Lynam | Assessing the conservation status of the tiger Panthera tigris at priority sites in Peninsular Malaysia[END_REF]). The smaller size of Krau reduced its capacity in providing adequate shelter for endangered animal and plant species in a context of forest fragmentation. However, Krau remains an important spot for lowland evergreen forest, while Taman Negara is still a stronghold for Southeast Asian biodiversity. It is very doubtful that such an achievement would have been possible had the initial project of Hubback been implemented. Hubback refused to take into account the claims of the local Malays and their interest. That led to resistance and opposition.

On the long term, the concessions that he and the other proponents of the preservation of wildlife were forced to make in the 1930s appear to have been beneficial for conservation, especially in the National Park.

In order to efficiently reproduce and implement this kind of participative model we need to be able to tell to the people living within or in the vicinity of a protected area what natural resources they can rely on, harvest of collect, without jeopardizing the whole conservation scheme. In order to do that, we need to be able to understand the dynamics of the whole ecosystem, which means understanding, among others, seeds dispersal processes [slide 9].