Fabien Bouffaron

David Gouyon

Dragoş Dobre

Gérard Morel
email: gerard.morel@univ-lorraine.fr

Revisiting the interoperation relationships between Systems Engineering collaborative processes

Keywords: Systems Engineering, Specification, Domain, Requirement

Systems Engineering (SE) best practices are currently guided by standardized processes which must be adapted by skill rules in order to specialize domain-dependent SE workflows as well as domainindependent standardized languages. This paper aims to revisit first the interdisciplinary relationships within a SE process as specification relationships between Problem Space (PS) and Solution Space (SS) across collaborative domains. This SE rationale is then applied on a Requirement Specification (RS) workflow formalized with high-level Petri nets and verified on a human-robot protection case-study.

INTRODUCTION

According to the SEBoK (Pyster et al., 2011), Systems Engineering (SE) is defined as "an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal". These SE activities are recursively organised according to five views and iteratively within each view related to "Business", "Requirement", "Architecture", "Integration Verification Validation Qualification" and "Configuration". These SE activities are guided by SE standardized processes as those of (ISO/IEC 15288, 2008). Overall, SE processes and standardized languages as SysML defined in OMG (2010), are designed as general purpose processes and languages. However according to [START_REF] Arthurs | Model-Based System Engineering, Elements for deploying an Efficient Development Environment[END_REF], "practioners want to solve specific problems, so the challenge becomes determining what modelling artefacts to use and how/when to use them efficiently to solve problems". Among many mandatory prerequisites such as "system thinking" to understand and to apply SE basics, one of the main is the problem-solution spaces partition which must be formally defined to become a SE basic construct. This partition means that any confusion between the roles assigned to any responsible specifying problems and any responsible specifying solutions would be to the detriment of meeting target system objectives [START_REF] Afis | Discover and understand systems engineering (v3)[END_REF].

Section 2 states on the iterative and recursive nature of this problem-solution spaces relationship defined as a specification key-artifact for SE right practices. This rationale is applied in section 3 to propose a generic workflow for the RS process. This workflow is tested in section 4 on a case-study related to the protection of human using robot. Section 5, draws a first assessment of this preliminary approach towards the transition to the industrial scale.

INTEROPERATION RELATIONSHIP WITHIN A SYSTEMS ENGINEERING PROCESS

This problem-solution spaces basic construct is studied in software development and automation domains before being generalized to the SE domain.

Software development issues

The problem-solution spaces interoperation has been studied by [START_REF] Berg | Tracing Software Product Line Variability -From Problem to Solution Space[END_REF] for traceability issues across domains whereas [START_REF] Czarnecki | Generative programming. Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models[END_REF] states that any domain can be divided into a PS and SS. According to [START_REF] Bjørner | From Domains to Requirements[END_REF], "by a domain we shall here understand a universe of discourse, an area of nature subject to laws of physics and study by physicists, or an area of human activity subject to its interfaces with other domains and to nature".

This interoperation relationship has been the subject of many researches in the field of computer science. [START_REF] Hall | Relating Software Requirements and Architectures using Problem Frames[END_REF] extend the problem frames approach [START_REF] Jackson | Problem Frames: Analysing & Structuring Software Development Problems[END_REF] towards the Twin Peaks model (Fig. 1) in order to define the iterative nature of the software development process as an iterative specification between problem and solution structures. 2002) Another works within the problem frames approach defined precisely the nature of a specification [START_REF] Gunter | A reference model for requirements and specifications[END_REF]. The proposed reference model (Fig. 2) gives five artifacts distributed among the environment domain and the system domain: the world knowledge W as a description of the relevant environment, the statement of requirements R, the specification S that mediates between the environment and the machine, the description of the machine M and the program P which executed on the machine M implements the specifi-cation S. In a more general way, the machine M with the program P represents the system to be constructed. [START_REF] Jackson | The meaning of requirements[END_REF] distinguishes two types of description of the environment: Description optative mood "expresses a condition over the phenomena of the environment that we wish to make true by installing the machine" and may be associated with R; Description indicative mood may be associated with W and "expresses a condition over the phenomena of the environment that we know to be true irrespective of the properties and behaviour of the machine". The separation between environment and system, according to [START_REF] Gunter | A reference model for requirements and specifications[END_REF] allows the separation of phenomena (states, events, individuals), owned and controlled by the environment e={e v , e h } or by the system s={s v , s h } (Fig. 2). Fig. 2. A reference model for requirements and specifications [START_REF] Gunter | A reference model for requirements and specifications[END_REF] On the one hand, there are phenomena e h , e v and s v visible to the environment and used in W and R. On the other hand, there are phenomena s h , s v and e v visible to the system and used in P and M. Therefore the specification S is expressed in the common phenomena s v and e v , and defined by (1):

,. esW S R "  (1)
Regarding this with a domain engineering point of view, [START_REF] Bjørner | Domain engineering. In Formal Methods;State of the Art and New Directions[END_REF], expressed that " Before Software can be designed we must understand the Requirements, and before Requirements can be expressed we must understand the Domain " and provides a formalization of the specification S in Domain D (2), where SR  means that S is a model of R:

, DS R  (2)

Automation issues

The above-mentioned interoperation relationship has been also studied in the field of automation in order to revisit the Fusaoka's automatic control synthesis condition (3) [START_REF] Fusaoka | Description and reasoning of plant controllers in temporal logic[END_REF] arguing that the design of any automation systems consists in prescribing the (unknown) control rules of the (known) dynamics of a physical system from the behavioural (known) goals to be met:

Dynamics Unknown Control Rules Goal É

(3) This weak prescription É is more broadly interpreted by Lamboley (2001) as a predicate implemented with a Bmethod based process:

C ontrol Specification Pr ocess Specification System Specification   (4)
To ensure the a priori correctness of each term of this automation predicate and their coherence as a whole, [START_REF] Pétin | Formal specification method for production systems automation[END_REF] propose a model-driven specification approach ensuring the predicate:

CO PP S  (5)
where the architecture P C  P O of automation P C of a process P O must satisfy the specification S.

Systems Engineering issues

Dobre (2010) combines recently these above mentioned works focusing mainly on specialist engineerings in order to take into account the interdisciplinary process required to engineer a system as a whole.

The predicate ( 5) must be re-formulated according to problem frames approach as:

CO WP P R  (6)
where W represents the context of the system-of-interest within the existing SS of the domain-of-interest. This interpretation considers that the domain-of-interest (i) is partitioned in two spaces of problem (Ps i ) and solution (Ss i ) and generalizes this partition to any domain involved in a collaborative SE process. Each interoperation relationship between a problem space Ps a and a solution space Ss b is considered as a contractual descriptive / prescriptive specification S ab . The resulting generalized SE specification process applies this rationale iteratively between Ps a and Ss b , and recursively [START_REF] Herzog | An approach to systems engineering tool data representation and exchange[END_REF] during the whole SE process (Fig. 3).

Fig.3. Iterative and recursive specification process 3 ITERATIVE INTEROPERATION RELATIONSHIP

FOR REQUIREMENT SPECIFICATION PROCESS SE process manipulates objects which are structured in metamodels. Among these metamodels, the one proposed by [START_REF] Holt | SysML for Systems Engineering Using a Model-Driven Development Approach[END_REF] places requirements as key objects for SE. Considering requirements, this section focuses on the relationship between system domain (seen as a PS) and SE domain (seen as a SS). It proposes a workflow, based on the evolution of requirement types and states that we see as an artifact of SE process, to aid the process of RS. According to [START_REF] Caron | Collaborative management of engineering data system[END_REF], a requirement type is defined by a "set of rules characterizing the relationship that the requirement of this type must or may have with other engineering data". Requirement state is defined by the fact that "some of these links are instantiated or not".

As the workflow is built upon various objects (presented in section 3.1) and various structured activities (presented in section 3.2), the language chosen to model it has to be able to express such specificities. Among candidates, high level Petri nets have been chosen because they enable to represent the variety of objects manipulated using colours and indexes, and to model structured activities using hierarchy in places. This workflow has then been formalized with CPN Tools [START_REF] Jensen | Coloured Petri Nets and CPN Tools for modelling and validation of concurrent systems[END_REF].

Objects used by the workflow

This section defines the various objects used during RS:

-Stakeholder requirement: expresses the expected system interactions with its environment; -Skill: is seen as the indicative mood within the meaning of [START_REF] Jackson | The meaning of requirements[END_REF]. It represents the known properties of system environment validated by an expert. Skills are required at each stage of the specification process, and can be for example characteristics of good requirements including characteristics about syntax or semantics (INCOSE, 2010), domain skills for transformation...

-Optative requirement: expresses a condition that is to be on the phenomena of the environment domain [START_REF] Jackson | The meaning of requirements[END_REF]).

An initial optative requirement corresponds to the description of a stakeholder requirement. An optative requirement can be verified or not verified, according to a verification activity which is detailed in the next section; -Transformation: corresponds to the requirement modification based on SS skills; -System requirement: a requirement which has to be satisfied by the future system, prescribed to PS. A system requirement can have several states: {Not Prescribed, Not Validated}, {Prescribed, Not Validated} and {Not Prescribed, Validated}. These states are defined by prescription and validation activities; -Specification: the set of all system requirements.

A static view of these objects and their relations, due to definition, description, transformation, prescription and validation activities, is formalized as a meta-model presented in (Fig. 4). Packages of meta-model represent different repositories to ensure traceability throughout the process of requirement specification.

Fig. 4. Meta-model used by the workflow

Iterative workflow between problem and solution spaces

The activities of RS, which compose the proposed workflow and are described below, are modelled by hierarchical transitions in a high level Petri net, while sets of requirements, including repositories, are modelled by places (Fig. 5). -Description Optative mood: description transforms a stakeholder requirement (from PS) into an optative requirement (into SS), but its content is not altered. This change of requirement type expresses that the requirement is addressed in another space. During description, a token (Stakehold-er_requirement(i),ID_SR(i)) becomes a token (Opta-tive_requirement(i),ID_SR(i)). Traceability between stakeholder and optative requirements is ensured because they have the same identifier; -Transformation: we have identified four transformation mechanisms: refinement, induction, decomposition and composition. For the last two, it is possible to add a suffix (AND, OR, XOR) to precise the relation between the requirements which are produced or used. For this reason, the transition "Transformation" of (Fig. 5) can be decomposed as presented in (Fig. 6) and an enumeration of types of transformations is given (Fig. 4).

Fig.6. Types of requirement transformations

All these transformations follow a same pattern, using (Pre)requirements and skills to generate (Post)requirements which have to be verified (Fig. 7). Considering these sets, the transformations are defined as:

-Refinement: the requirement « preR n » refined with the skill « sk i » produces the refined requirement « postR m ». The skill « sk i » bridges the gap between « preR n » and « postR m ».

-Induction: the requirement « preR n » with the skill « sk i » induce a new requirement « postR m » while retaining the requirement « preR n ». « k i » is a skill from which is induced « postR m »; -Decomposition: (Decomposition_AND, Decomposition_OR and Decomposition_XOR) the requirement « preR n » can be decomposed into a set of requirements {postR m ,postR m+1 ,…, postR m+n } where n+1 represents the number of decomposition, using the skill « sk i » to justify the decomposition; -Composition: (Composition_AND, Composition_OR and Composition_XOR) the set of requirements {preR n , preR o ,..., preR x }» can be composed into a requirement « postR m », using the skill « sk i » to justify the composition.

For each transformation, a quadruplet token (PreRequirement, TOT, Skill, PostRequirement

) is created. PreRequire- ment is a List[Optative_requirement(i), ID_SR(i)]. TOT is the Type Of Transformation completed, Skill is the Skill(i) that enabled the transformation. PostRequirement is a List[Optative_requirement(j), ID_SR(j)].
-Verification: after each transformation, the compliance of the set PostRequirement with the set PreRequirement is verified. If it is unverified, the set PreRequirement is returned to the place Optative requirements. Otherwise if it is verified the set PostRequirement is returned, and a quadruplet token (PreRequirement, TOT, Skill, PostRequirement) is stored in the repository System requirement repository thereby making the traceability between the requirements of different levels; -Transformation End: after several transformations, the set of optative requirements obtained is, according to the skill (Skill(i)), at a system level. Accordingly a token (Opta-tive_requirement(i),ID_SR(i)) becomes a token (Sys-tem_requirement(i),ID_SR(i)). Traceability between optative and system requirements is ensured because they have same identifiers;

-Prescription: during this activity, system requirements issued from a same stakeholder requirement are simultaneously prescribed to PS for validation. The statement of requirements remains the same but the requirements change from state Not Prescribed to Prescribed; -Validation: during validation, the client validates all systems requirements issued from a same stakeholder requirement, considering the links between them which are stored in the System requirements repository (Fig. 8). This is to ensure that the SS clearly understands and expresses the stakeholder requirements, and that the compromises made are acceptable. If it is not validated, a token (Optative_requirement(i), ID_SR(i)) is returned in place Optative requirement. This optative requirement corresponds to the stakeholderrequirement described (Stakeholder_requirement(i),ID_SR(i)) from which the validation was performed. If it is validated, the set of system requirements (System_requirement(i), ID_SR(i)) is sent to the place Specification, and changes from Not Validated to Validated. Moreover, a couple token (List[Stakeholder_requirement(i)],

List[System_requirement(i)]) is stored in Problem requirement repository. This token links stakeholder requirements described and system requirements prescribed as answers. The proposed workflow is illustrated on a case study from the training center AIP-Primeca Lorraine (http://www.aipprimeca.net). To be compliant with the French labour code, the AIPL develops and implements security systems to prevent risky situations. For example, the power supply of the 6axis articulated robot should be cut if a door of its protective enclosure is open.

In the PS, this need can be defined by a stakeholder requirement: Stakeholder_requirement(1): "Robot power supply must be cut if a door of the protective enclosure is open". A token (Stakeholder_requirement(1),[ID_SR(1)]) is put in place Stakeholders requirements and is also stored in the repository Stakeholders requirements repository. 2), [ID_SR(1)])}. This is presented by place "3-PreRequirement/TOT/Skill/PostRequirement" of (Fig. 10), in which the contained token means that the Opta- tive_requirement(1), in connection with the stakeholder requirement of index ID_SR(1), can be refined thanks to Skill(1) to produce a new requirement Optative _requirement(2) in connection with the stakeholder requirement of index ID_SR(1). Once completed the Refinement, the correctness of the transformation is checked using verification rules. Considering that the transformation is correct, a new Optative_requirement(2) is obtained. Moreover a new token ( [(Optative_requirement(1)

, [ID_SR(1)])], Refine- ment,Skill(1),[(Optative_requirement(2), [ID_SR(1)])], [ID_ SR(1)]

) is put in place "Solution Requirement Repository", to ensure traceability between Optative_requirement(1) and Optative_requirement(2) according to the Skill(1).

After transformation, a token (Optative_requirement(2), ID_SR(1)) is in place Optative requirements. A skill, Skill(2): "Sensors are in the interface between the system to design and the environment represented by the robot" defines that this requirement is at system-level, accordingly transformations can be stopped, and this optative requirement becomes a system requirement (System_requirement(2), ID_SR(1)). Once the SS has defined system requirements to answer all initial optative requirements, they are prescribed to the PS for validation. Thus, (System_requirement(2), ID_SR(1)) is prescribed to PS, and is finally validated with respect to the stakeholder requirement (Stakehold- er_requirement(1),ID_SR( 1)) from which it comes. Then, (System_requirement(2), ID_SR(1)) is placed in place "Specification". Finally, a couple token ([Stakeholder requirement(1)], [(System_requirement(2), ID_SR( 1))]) is stored in place "Problem Requirement Repository" ensuring traceability between stakeholder requirement and system requirement. Although these works are preliminary, well formulating basic SE constructs is of importance for engineering use as well as for training purposes. As example, SysML, the de-facto domain-independent system modelling language defined in OMG (2010), remains controversial for Model Based Systems Engineering domain dependent because of its too general semantics. Applying our approach leads to improve this semantics for specification issues by manipulating modelling objects (dependencies, boundary-box,...) based on defined constructs as optative-indicative moods, problem-solution spaces, World/Domain which turn out to be already efficient in practice within the requirement definition process. Current work aims to enrich SysML metamodel by stereotyping the proposed constructs and by developing new system modelling objects.

Transition to more operational context is on-going in order to prove the relevance of the proposed workflow at the industrial scale. First application is related to railway embedded control system, in order to formally control passenger access through train door. A second application is related to the formal specification of a computer-aided device to improve human-based plant operation [START_REF] Dobre | Contribution to the modelling of an interactive system driving assistance of an industrial process[END_REF].

Fig. 1 .

 1 Fig.1. Variation of the Twin Peaks model by Hall et al. (2002) Another works within the problem frames approach defined precisely the nature of a specification[START_REF] Gunter | A reference model for requirements and specifications[END_REF]. The proposed reference model (Fig.2) gives five artifacts distributed among the environment domain and the system domain: the world knowledge W as a description of the relevant environment, the statement of requirements R, the specification S that mediates between the environment and the machine, the description of the machine M and the program P which executed on the machine M implements the specifi-

Fig. 5 .

 5 Fig.5. Main structure of the iterative workflow proposed for RS

Fig. 7 .

 7 Fig.7. Transformation pattern Let R, PreR, PostR and SK the sets of elements manipulated during transformations: -R = {preR 1 ,…,preR n ,postR 1 ,…,postR m }, n N,I , mN,I , the set of optative requirements; -PreR = {preR 1 ,…,preR n }, nN,I , the set of optative requirements to transform, PreR  R; -PostR = {postR 1 ,…,postR m }, mN,I the set of optative requirements transformed, PostR  R; -SK = {sk 0 ,sk 1 ,…,sk i } the set of domain skills. For each transformation skill sk i SK can have a different role.

Fig. 8 .

 8 Fig.8. System requirements validation

Fig. 9

 9 Fig.9. 6-axis articulated robot with a protective enclosure Firstly, the PS describes to the SS the couple (Stakehold- er_requirement(1),[ID_SR(1)]) that becomes the couple (Optative_requirement(1),[ID_SR(1)]). Secondly, a Skill(1): "The robot is equipped with a power input board with two inputs FN1 and FN2 on which is connected a switch installed on the door. They enable to cut the power supply of the robot if the switch is open" informs that Optative_requirement(1) can be refined into a new requirement Opta- tive_requirement(2) "Security access door enslavement must be connected with inputs FN1 and FN2 of the power input board". Considering the pattern of transformation previously defined, we have {PreRequirement = [(Opta-tive_requirement(1), [ID_SR(1)])], TOT = Refinement, skill = Skill(1), PostRequirement = [(Optative_requirement(2), [ID_SR(1)])}. This is presented by place "3-PreRequirement/TOT/Skill/PostRequirement" of (Fig.10), in which the contained token means that the Opta- tive_requirement(1), in connection with the stakeholder requirement of index ID_SR(1), can be refined thanks to Skill(1) to produce a new requirement Optative _requirement(2) in connection with the stakeholder requirement of index ID_SR(1). Once completed the Refinement, the correctness of the transformation is checked using verification rules. Considering that the transformation is correct, a new Optative_requirement(2) is obtained. Moreover a new token ([(Optative_requirement(1), [ID_SR(1)])], Refine- ment,Skill(1),[(Optative_requirement(2), [ID_SR(1)])], [ID_ SR(1)]) is put in place "Solution Requirement Repository", to ensure traceability between Optative_requirement(1) and Optative_requirement(2) according to the Skill(1).

Fig

  Fig.10. Refinement of requirement Optative_requirement(1) from Skill(1)


Nicolas Denoyelle

Florian Pouget

Thierry Vieville

Frédéric Alexandre
email: frederic.alexandre@inria.fr

VirtualEnaction : A Platform for Systemic Neuroscience Simulation

Keywords: Simulation, Computational Neuroscience, Virtual Reality

Considering the experimental study of systemic models of the brain as a whole (in contrast to models of one brain area or aspect), there is a real need for tools designed to realistically simulate these models and to experiment them. We explain here why a robotic setup is not necessarily the best choice, and what are the general requirements for such a bench-marking platform. A step further, we describe an effective solution, freely available on line and already in use to validate functional models of the brain. This solution is a digital platform where the brainy-bot implementing the model to study is embedded in a simplified but realistic controlled environment. From visual, tactile and olfactory input, to body, arm and eye motor command, in addition to vital somesthetic cues, complex survival behaviors can be experimented. The platform is also complemented with algorithmic high-level cognitive modules, making the job of building biologically plausible bots easier.

INTRODUCTION

The brain is a fascinating complex structure and designing global models of such a structure is particularly difficult. This is specifically true with regard to the fact that the brain is a complex system in interaction with the body and the environment. Two important consequences can be driven. On the one hand, modeling the brain includes not only understanding how each subsystem (visual, motor, emotional, etc.) works but also how these subsystems interact as a whole, to yield emerging behaviors, i.e. effects that result from interactions between subsystems. On the other hand, studying and validating functional models of brain structures at a macroscopic scale cannot be performed with restrained artificial static paradigms but requires experiments in complex environments, with realistic sensory-motor tasks to perform, including high-level interactive behaviors (e.g. survival strategy in the presence of prays/predators) and longterm protocols (since both statistical studies and bioplausible learning mechanisms require long epochs). Such paradigms are to be related to biological experiments conducted on animals. These statements are not only characterizing brain models, they also give strong requirements on the tools that must be designed to simulate these models and to experiment them.

Designing such tools is also an excellent way to address at the same time the two main objectives of such brain models at the macroscopic scale. One the one hand, they are intended to serve neuroscientists as a new platform of experimentation, on which they can apply their classical protocols of observation and analysis of animals at the behavioral as well as electrophysiological levels. It is consequently important that neuroscientists can observe the inner activity of the models, as they use to do for example with electrodes (but we can imagine that this observation in digital models might be more easy than in the real brain). It is also important that they can define classical behavioral protocols like they do in animals (eg. fear conditioning) in order to observe the resulting behavior and the corresponding brain activation. Defining such protocols implies that the structure of the external world (e.g., maze, food magazine) as well as its intrinsic rules (eg. tone followed by an electric shock) be easy to design.

On the other hand, they are also intended to serve computer scientists as a way to design artificial autonomous systems, driven by the brain models. In this case, it is important that the supposed properties of the models (e.g., capacity to learn, robustness to noise or changing rules) be assessed by rigorous eval-uation procedures, as it is defined for example in the domain of machine learning. In this case also an easy access must be proposed both to the inner circuitry of the models and to the specification of the external world.

With in mind this double goal of offering convenient tools to both scientific communities, we report in this paper the specifications that we have elaborated and present the corresponding software platform that we call VirtualEnaction.

PROBLEM POSITION

Concerning the nature of such a simulator, real robotic systems are often used and answer particularly well to the second requirement about a realistic environment. However, building viable robotic systems and making them evolve in realistic environments (e.g. natural sites) for long periods of time (e.g. several days) is just too expensive in term of cost and manpower in many circumstances and particularly during early phases of development. Furthermore, the goal of such simulation is not only to make a demo, but also, and more importantly, to study and quantify the behavior of functional models of the brain. As a consequence we not only need a complex, long-term, realistic experimental setup, but we also need a controllable and measurable setup where stimuli can be tuned and responses can be measured. In fact, real environment complexity and parameters are intrinsically difficult when not impossible to control. This is the reason why we propose to use a digital simulator implementing realistic survival and other biological scenarios A step further, available macroscopic models of brain functions are not designed for "performance" but to properly implement phenomenological concepts that have been investigated in some cognitive or behavioral framework. They would therefore have "no chance" in a real world. Note that recent computer science mechanisms designed without any constraint regarding biological plausibility but only towards final performances are nowadays probably more efficient but explain nothing.

As a consequence we also need a setup which can provide a "simplified environment", in order systemic models of the brain at the state of the art not to fail immediately. We must also take into account the fact that (i) such models are rather slow to simulate (unless huge computer power is available), and that (ii) they are not supposed to focus on precise issues regarding low-level sensory input or motor output but on integrated cognitive functions and the resulting be-haviors.

This, in addition to technical constraints, yields three key characteristics: 1. No real-time but a look-and-move paradigm : The main restriction we propose to accept here is to have the simulator running at a "slower" time (i.e. using several seconds to simulate one real-time second) and also to consider discrete time sampling. This seems obvious as far as digital simulation is concerned, but in terms of underlying framework, this has several consequences (e.g., giving up the possibility for a human observer to interact with the simulation, restraining to clockbased (and not event-based) dynamical models, etc.) [START_REF] Taouali | No clock to rule them all[END_REF].

2. No real robotic control but only motor command : Since in the nervous system motor control seems to be a hierarchical system with high-level motor commands, while their closed loop execution is delegated to the peripheral motor system [START_REF] Uithol | Hierarchies in action and motor control[END_REF], we may accept to only simulate gesture and displacement at a rather symbolic level such as "stand-up" or "turn 90 • rightward". This indeed cancels the possibility to study sharp phenomena of motor interactions with the environment but allows us to concentrate on high-level control such as action selection mechanism and motor planification.

Complex but not necessarily natural visual environment:

The third main restriction we propose to accept is to consider a complex visual environment (with visual textures, several objects in motion, etc.) but not to invest in the simulation of a realistic natural scene simulation. The reason of this choice is that natural image vision is an issue already well studied [START_REF] Hyvärinen | Natural image statistics a probabilistic approach to early computational vision[END_REF]. The general conclusion is that biological visual systems are tuned to natural image statistics, decomposed by the early visual front-end in such a way that higher-level visual input only relates on cues orthogonal (in a wide sense) to natural image statistics. In other words, the job regarding this aspect is done by early-vision layers and we may consider more stylistic visual cues at a higher-level.

Depending on the study, we may also wish to work on either a pixelic or a symbolic representation of the visual scene. See [START_REF] Teftef | Modeling non-standard retinal in/out function using computer vision variational methods[END_REF] for details of how the early-visual system relates both representations.

We consider that a "brainy-bot", i.e. the implementation of a global model of the brain functionality, interacts with its environment with the simple goal to survive. Our objective is to simulate the sensorymotor interactions of this bot with respect to its environment. Examples of such surroundings are shown in Fig. 1.

Figure 1: Two examples of digital experimental environments for systemic neuroscience. Up: A minimal environment corresponding to a standard maze reinforcement learning task (source: one of our virtual enaction built). Down: A complex environment in which survival capabilities are to be checked (source: landscape encountered when playing with the standard game).

Survival is precisely defined as maintaining vital variable values in correct ranges, as formalized in, e.g., [START_REF] Friston | A Free Energy Principle for Biological Systems[END_REF]. In our context, health, food, water, energy, and oxygen are the vital state variables. The bot has access to these values. These variables decrease or increase with time since the bot body is supposed to consume the related resource depending on its activity, or change in the presence of an external event (e.g. energy during a predator attack), and restore resources. Restoring resources is obtained either by ingesting items or taking rest (i.e., make the choice to stop action, with the benefit of vital resource increase and the drawback of not acting on the environement, this might be a short-term policy choice if vital variables are low and is a middle-term policy choice otherwise).

The environment structure is very simple and made of "blocks". Each object in this environment (including the floor, relief, ..) is a collection of blocks. Each block is defined by its 3D position, orientation and sizes, roughness, hardness, temperature, and color. Some blocks correspond to eatable or drinkable resources. Other entities correspond to objects that interact with the bot (e.g. predators that attack the bot or lava to avoid). At this level, survival corresponds to avoid or kill the predators and find resources to eat or drink.

The bot anatomy is functionally made of a body, an arm and an head/eye. It carries a bag with objects found in its environment. The body can move at a given speed and in a given direction, and also rotate at each step to a given angle. It can also jump up to a given relative height, or knee down to take a rest. The head/eye can gaze in a given yaw/pitch direction. The arm can perform predefined symbolic gestures : take an object in hand out of its bag, put the object in hand into its bag, either drop or throw the object in hand, ingest the block in hand (food or water), grasp the object in front of him. The arm can also attack (quantified by a force value and with or without an object in hand) the object in front of him. This is the complete description of the bot motor command output in the present context.

The bot sensory input corresponds to cues related to the blocks which are around it. The touch cues allow the bot to estimate the roughness, hardness and temperature of the object in hand. The olfactory cues allow to estimate the smell type and intensity of objects close to it (computed by integrating average values over the blocks characteristics). At the bot level, pixelic vision provides an image of the visual field view (i.e., calculating the blocks texture and color projection on the virtual retina). Finally, the proprioceptive cues correspond to gaze direction estimation.

In order to quantify the bot behavior, the interface provides an additional access to the bot absolute position and orientation in space. Symbolic vision is also available, as a list of blocks visible in its visual field, which access to the block characteristics.

An adaptation of the minecraft open game software yields the proper answer to this wish-list and the so called virtualenaction is an open-source freelicense implementation of these specifications. Each user buys a end-user low-cost mojang license (< 20$) for minecraft, while virtualenaction is free of use under a CeCILL-C license. Fully-documented scripts facilitate the installation of the software bundle under Linux OS. The bot is implemented in either C/C++, or possibly in Python (via an existing swig wrapper) or other computer languages. It uses a simple API, as described in Fig. 2. Furthermore, in order to both observe in slow-down real-time the bot behav- ior and interact with the digital experiment, a graphic user interface is available as described in Fig. 3.

More details on the computer implementation is given in Appendix B.

NEUROSCIENCE APPLICATION

Let us now discuss how this setup constitutes a step towards integrative neuroscience digital experimentation.

First of all, let us compare this project with complementary connected projects. The AnimatLab is a software platform allowing to simulate embodiment (bio-mechanical simulation of a body) allowing investigate the relation between brain and body [START_REF] Cofer | AnimatLab: a 3D graphics environment for neuromechanical simulations[END_REF]. Furthermore, it proposes a neural network architecture for the implementation of cognitive function. On the contrary, the present framework has a rather limited description of the embodiment, but a much larger set of possible interactions with the environment. A step further, not only artificial based neural network models are usable in VirtualEnaction, whereas the interface with any existing neuroscience simulation tool (e.g., python based neural simulators, see [START_REF] Brette | Simulation of networks of spiking neurons: a review of tools and strategies[END_REF][START_REF] Davison | PyNN: A Common Interface for Neuronal Network Simulators[END_REF]) is straightforward. This feature is essential, since we must simulate the system at different modeling scale, as developed now. The Morse is a generic simulator for academic robotics, with realistic 3D simulation of small to large environments, allowing complete integration with any simulation tools. It outperforms concurrent systems like Webot. The interest of Vir-tualEnaction with respect to Morse is twofold: Since we target integrative cognitive tasks of survival which is exactly what happens with the Minecraft environment, using this specialized product is far simpler and somehow more demonstrative. In term of per-formances, as being less sophisticated (using a simplified 3D rendering, while Morse has all 3D capabilities) and being agnostic in terms of programming languages (i.e., allowing fast C/C++ implementation of user modules, whereas Morse is limited to Python scripts) the VirtualEnaction platform is a priori expected to be more efficient in terms of CPU usage. However, with a larger humanpower all what has been developed within VirtualEnaction could have been developed in Morse.

The main application regarding neuroscience is to test cognitive computational models in realistic conditions. Very simply, a behavioral experiment is performed on an animal model or on human. Usually with a training phase, the measurement phase and the data analysis. In order to formalize the obtained result a computational model is proposed that explain the data, and may also have prediction regarding other falsifiable future experiments. The present software and methodological tool allow us to propose to enhance this very general paradigm in the following directions:

• Test the model prediction for several others experimental conditions or model parameter ranges :

The idea is to reproduce the experimental setup in this virtual environment (e.g., a delayed reward task, an exploration paradigm) and connect the computational model to this paradigm. As for usual computational modeling, the chosen biological measurements (e.g. neural activity, task success performance) are simulated when running the model. Such model is indeed expected to reproduce qualitatively the ground truth, for a given set of parameters value. A step further, it is very important to numerically verify what happens when modifying any quantitative or qualitative parameter value. If the numerical sensibility is so strong that the results cannot be reproduced for some tiny parameter variation, the model is meaningless because biological values make sense as a numerical range, not a single number. If the numerical sensibility is so weak that any parameter value produces the expected result, this parameter is meaningless and a simpler model very likely explains the same data set. The key-point here is that such usual model predictive verification is not only going to be possible, given a fixed data set, but for any data set obtained running experiment in the virtual environment. In other words, the computational model variants are going to be always tested in-situ. With no practical bounds on the experimental variants (e.g., number of trials, sensory input precision, task complexity).

• Design new experimental paradigms to confront Figure 3: The software's graphic user interface. In order to observe and control the experiment, a view of the bot vision, status, input and output is available via interactive panels. It is also possible to "cheat" by controlling these variables values, in order to debug an experiment and understand in details what happens in such a complex system interaction.

the computational model to falsifiable conditions :

Building on an animal model an experiment, training the animals for weeks, restarting from the beginning, if it appears that there is an unexpected trap (e.g., the task in too simple or unfeasible, or does not allow to discriminate between two concurrent models) may be a huge work. Starting to design the experiment in a virtual environment completely changes the method: the hypothesized computational model is first tested in silico (i.e., neither in vivo, nor in vitro, but in a software environment) and only confronted to the biological reality in a second stage. The workplan is inverted with respect to usual neuroscience studies, but in computational engineering (e.g., designing new airplanes) this is exactly the way it goes until a few decades. It is however not new in neuroscience, at the scale of mesoscopic brain map study (see e.g., [START_REF] Chemla | Biophysical cortical column model for optical signal analysis[END_REF] or [START_REF] Brette | Simulation of networks of spiking neurons: a review of tools and strategies[END_REF]). The key point here, is that such approach is now possible at the behavioral level, considering sensory-motor interactions with a simple or complex environment. Such process also obviously yields a parsimonious use of animal models. A step further, it lays down the challenge to perform realistic experiment with a computational model of the brain behavior, not only consider toy situations where the plausibility of the model can not be checked.

The degree of equivalence between simulation outcome and neuroscience experimental results is key issue. This is the reason why we have chosen a software platform where usual systemic neuroscience experiments can be reproduced "as a whole", as illustrated by several examples throughout this draft. Basis omissions (e.g., level of modeling detail) have been justified or rejected, in order to attain this objective of simulating classes of behavioral experiments where the subject is trained to realize a survival or rewarding task in a known or unexpected environment. Applications include Pavlovian (e.g., action of the amygdala) or operant conditioning, reinforcement learning, training and habituation, task oriented focus of attention, multi-sensory interaction. The main brain structures involved in such tasks are the basal ganglia system (including afferent and efferent structures) regarding selection of action, the different memory structures (e.g., episodic memory in the hippocampus, or working memory in the prefrontal cortex).

DISCUSSION

Beyond these basic features, the input and output can be easily manipulated in order to enlarge the experimental setup. Up to now, the main aspect is "input or output degradation", i.e. adding noise. Originally, bot perception and action are performed without any added noise or random mistake. Depending on the experiment to be conducted, it is obvious (i.e. inserting a few lines of code between the platform and the bot), either to reduce variables precision range (e.g., add noise to the pixelic image) or to randomly draw the fact that a gesture may succeed or fail (e.g., introduce spurious command).

A step further, as already implemented as plugins, since all environment elements are available (not to the bot, but to the experiment software), it would be possible to design other cues, or more generally other interactions with the environment. However, in collaboration with neuroscience experimentalists, we have carefully selected what seems useful to explore biological systemic models, and avoided to provide a too general tool that do anything.

Building one "brainy-bot" is a rather huge task and requires several high-level cognitive functionality. However, though systemic neuroscience requires to study the system as a whole, it does not imply that each functionality has to be studied at the same level of details. Several blocks may be considered as blackboxes interacting with the part of the system to be extensively studied. This is the reason why the present platform is not limited to a survival environment, but comes also with middle-ware (presently in development) related to the basic cognitive functionality involved in such paradigms, as listed in Appendix A. Some modules will thus be implemented according to a rough description, e.g., via an algorithmic ersatz. The nervous sub-system under study, on the reverse is going to be implemented at a very fine scale (neural network mesoscopic models or even spiking neural networks).

The key features of this digital experimentation platform include the capability to perform experiments involving both long-term continuous time paradigms or short-term decision tasks with a few time-steps. It also allows us to consider either symbolic motor command or sensory input (e.g., ingest or not food, detect the presence of a stimulus) or quantitative gestures and complex trajectory generation (e.g., find resources in an unknown environment).

A key point is to be able to mimic and repeat at will experiments performed in neuroscience laboratory on animals. Here, the obtained computational models are not only going to "fit the data" but to be explored far beyond, yielding the possibility to study long-term adaptation, statistical robustness, etc. Not only one instance of a bot can be checked, but several parallel experiments can be run in order to explore different parameter ranges, or compare alternative models.

It would also be instructive to better understand to which extent such bio-inspired architectures actually required to control a biological system could enhance artificial control rules commonly applied in robotics or game engines. This is a challenging issue, beyond the present study, but an interesting perspective of the present work.

As a conclusion, let us mention that this platform has already been used for preliminary digital experiments about Pavlovian conditioning [START_REF] Gorojosky | Models of Hippocampus for pavlovian learning[END_REF] involving the functional modeling of the amygdala and hippocampus, decision making mechanisms in link with reinforcing signals yielded by aversive or appetitive stimuli and internal computation [START_REF] Beati | Which reinforcing signals in autonomous systems?[END_REF], plus a student work of the AGREL connexionist categorization model here confronted to a realistic environment [START_REF] Carrere | Émergence de catégories par interaction entre systèmes d'apprentissage[END_REF].

ACKNOWLEDGMENTS This work was partly supported by the KEOpS ANR project. Huge thanks to Nicolas Rougier for precious advises and Maxime Carrere for his feedback. The NeBICA'14 review was a real chance to improve the original draft, thanks.

A BRAINY-BOT GENERIC FUNCTIONALITY

Even when restraining to functional modeling, it is not possible to simulate all sub-systems of the brain at the same level of details. In order to help representing the part of the system that may be simulated with-out biologically plausible models in a given context, a few sets of functionality are proposed. Let us briefly present the main algorithmic cues.

-Episodic memory of input/output: Any system has not only to take into account the present input and output in order to generate a proper behavior, but also store and consider the recent past information. In the brain, this function is mainly located in the hippocampus. In our context, thanks to the design choices, such information corresponds to a simple file of symbolic information, namely a hierarchical itemization of parameter values (i.e. a XML data structure). As a consequence, the memorization, transmission, compression (in the sense of eliminating negligible values or values related to older or smaller elements) is easy to well-define. It has also the consequence to propose a generic internal representation of the sensorymotor information at a symbolic level, without bothering about how this information is encoded on neural maps. It is an interesting perspective of the present work and an ongoing work to further investigate this issue, while basic algorithmic modules for such data management are already available.

-Trajectory generation: At a functional level a "behavior" (i.e., a complex gesture) can be specified as finding a path from an initial state (e.g., being hungry while food is known to be present elsewhere) to a final state (e.g., having the food ingested) taking constraints into account (e.g., avoiding or moving aside obstacles on the way). Such issue may be a topic, or not (e.g., when studying the selection of action we may prefer not to bother with the planification and execution of such actions). In the latter case, Figure 5: The platform underlying protocol. At the system level, the synchronization between the existing game events and the different system component is a non trivial middle-ware, taking into account both "real players" (thus playing in real time) and "bot players" (with slow reaction delays). The developed middle-ware can cope with several bots and humans (which will have to be patient, since the game runs at a reduced rate). Furthermore, the design allows the platform to be distributed on a cluster (server, client and bots running on different machines).

generic specification of such problem and universal algorithms to solve them exist, in relation with harmonic control which is a biologically plausible framework (i.e., with fully distributed computation based on diffusion mechanism) [START_REF] Viéville | An improved biologically plausible trajectory generator[END_REF].

-Generic categorization: Another generic key cognitive feature is the capability to "extract" symbolic information from a bundle of quantitative or qualitative values. This includes sensory events detection (e.g., detect the presence of predator from sensory cues), object labeling (e.g., an element as a resource to ingest). Though such issue is indeed a topic on its own, we may wish in some context to have it available as a black box. A biologically plausible support vector machine mechanism is available to this end, with versatile uses [START_REF] Viéville | Using an Hebbian learning rule for multi-class SVM classifiers[END_REF]. Let us also mention that informing the bot about its absolute position and orientation or about symbolic information of the scene is a way to shortcut its sensory modules and provide integrated cognitive information.

B COMPUTER IMPLEMENTATION

This experimental virtualenaction setup is fully documented both at the user [START_REF] Denoyelle | Virtualenaction, user documentation[END_REF] and developer [START_REF] Pouget | Virtualenaction, developer documentation[END_REF] levels. The user view of the computer implementation is oversimple as illustrated in Fig. 4, though the underlying computer development is not that trivial as sketched out in Fig. 5. It runs a bukkit server in the 1.4.5 version and is designed as a set of plugin for this server, with minimal changes in the original code. This design choice was optimal in terms of middle-ware development effort and fi-nal code stability. At the server level, two plugins have been designed. The VirtualEnaction plugin allows us to replace usual player mouse and keyboard interactions with the game-play by a programmable API. The Characteristics plugin allows us to implement blocks and entities additional characteristics such as temperature, hardness or smell.

The minecraft server and client have been modified in order to be able to run in this programmatic mode, and to get a full access to all game gauges, because we not only must run the bot but also observe in details its behavior and measure all interactions with the environment. As a consequence, the actual source code corresponds to a fork of a frozen version of the minecraft game, while everything is documented in order to easily migrate to some more recent version.

Another key point is the modification of the environment. Using the standard game, it is possible to build an environment, include other entities, and so on. This is simply realized via the game interface. Futhermore, scripted scenarios can also be introduced (e.g., some resource appears if and only if a block is put in a given position), as additional plugins. In addition, configuration files on the server side, allows us to act on available resources or survival gauges, and build versatile survival situations. It is thus a fully editable setup. As being an open-source collaborative software, it is available on the Inria forge with more than 15 co-developers or project followers.

A step further, in order this virtual experimentation platform to be extensible in the perspective of new setups, the botplug that allows the bot to be plugged in the client/server system is also designed with a notion of plugin. For instance, a tactile sense (not described here), and a variant of the pixelic vision to be connected to different image sequence computation libraries are made available as plugins.

It is clear that several extensions are going to be developed in a near future thanks to this modular architecture choice.

Figure 2 :

 2 Figure 2: Left: The software interface is trivial: each implementation of a brainy-bot provides an initialization routine initBot() and a stop function stopCondition(), while at each time-step the brainDo() method is called. Right: All status, input and output functionality are available via a simple API. For instance, hand or vital input, body and head displacement, gestures of resource injection and attack against predator are shown.