Kristine Lund
email: kristine.lund@univ-lyon2.fr

Céline Rossetti
email: celine.rossetti@univ-lyon2.fr

Stéphanie Metz
email: stephanie.metz@univ-lyon2.fr

Do internal factors of cooperation influence computer-mediated distance activity?

Keywords:

.

Introduction

The models of cooperation elaborated in domains dealing with problem resolution aided by computers focus on a variety of phenomena. For example, they address spatial aspects of virtual worlds [START_REF] Benford | A Spatial Model of Cooperation for Virtual Worlds[END_REF], decision processes carried out through a distributed information system [START_REF] Gachet | Distributed Decision Support Systems -A Federalist Model of Cooperation[END_REF] or forms of cooperation as reflected by dyadic interactions [START_REF] Baker | Forms of cooperation in dyadic problem-solving[END_REF]. This last model of cooperation -the only full-fledged model amongst those cited above -is interesting in that it distinguishes different forms of cooperation within a dyad. Making these forms explicit helps us to understand how participants organize themselves when they solve a problem together. This organization is a function of the dimensions of activity that make up the model. From the moment that these forms are defined, it becomes possible to evaluate which of them characterize those interactions that are favorable for learning [START_REF] Jakobsson | Learning Attitudes Decisive to Students Cognitive and Knowledge Development[END_REF]Burton, Brna & Treasure-Jones, 1996;[START_REF] Baker | Forms of cooperation in dyadic problem-solving[END_REF]. Alternatively, it becomes possible to study which forms of cooperation would produce a final product of greater quality, for example in the case of design. But on which basis should we choose the dimensions of activity that are used to elaborate the forms of cooperation? And what factors can be related to these dimensions and in consequence, influence the forms of cooperation?

A model of cooperative activity and factors influencing cooperation

In the conceptual model of cooperative activity during problem resolution described by [START_REF] Baker | Forms of cooperation in dyadic problem-solving[END_REF], three principal phenomena appear upon observing people that work together: 1) different responsibilities and contributions, 2) the way in which people carry out their work together (e.g. each person's speed, mutual understanding), and finally 3) the presence or absence of agreement. The objective of Baker's model is to establish a link between cooperative activity and learning through the combination of three fundamental dimensions: role symmetry, alignment and agreement. (cf. Table 1).

Table 1. The fundamental dimensions of [START_REF] Baker | Forms of cooperation in dyadic problem-solving[END_REF] model of forms of cooperation Dimension Definition Degree of symmetry For a given continuous sequence of interaction, the similarity or difference in the responsibilities of participants in regards to the accomplishment of sub-tasks, such as is manifested in verbal or non-verbal communication, linked to material resources.

Degree of

The difference in propositional attitudes (belief, non-belief, acceptance, non-acceptance) that are agreement manifested publicly, in relation to the different aspects of cooperative activity of problem solving (solutions, goals, methods, actions). Degree of alignment The extent to which partners are "in phase", in relation to aspects of their cooperative problem solving (phases, degree of mutual comprehension, conceptualization of problem).

In the case where the values of the dimensions are binary (e.g. symmetrical / non-symmetrical, etc.), the three dimensional space corresponds to eight specific forms of cooperation (cf. Figure 1).

Figure 1. The eight basic forms of cooperation in the cooperative activity of problem resolution, redrawn from [START_REF] Baker | Forms of cooperation in dyadic problem-solving[END_REF].

A study of the literature revealed factors that contribute in diverse ways to collaboration. However, they are not put into relation with a model that describes the forms of collaborative activity through precise dimensions, such as those in Baker's model (see above). This is the objective of our article. We organized the factors we found in the literature into two types: internal and external. Each type of factor contains examples of different granularity. In regards to internal factors, a factor can be internal to the individual or internal to the interaction between individuals.

The factors that are internal to the individual are for example, self-efficacy [START_REF] Bandura | Self-efficacy[END_REF], adherence to the working principle, altruism or favorable opinion of collaboration as an approach to problem solving [START_REF] Suangsuwan | A Development of indicators, and the Cause and Effect Model of Collaboration of Primary School Teacher in Ayutthaya province, Thailand[END_REF]. There are also numerous factors internal to the interaction between individuals. For example, the structuring of communication at a distance [START_REF] Baker | Promoting reflective interactions in a computer-supported collaborative learning environment[END_REF], the socioinstitutional roles of participants [START_REF] Lund | Analyse de l'activité explicative en interaction : étude de dialogues d'enseignants de physique en formation interprétant les interactions entre élèves [The analysis of interactive explanatory activity: a study of physics student teachers' dialogues as they interpret student interactions[END_REF], the exchanges of a social nature at the beginning of an interaction (van Amelsvoort & Andriessen 2003), and finally the extent to which participants take into account non-verbal body language (Gregori & Brassac, 2001) are all correlated with diverse ways of describing how collaboration occurs.

The external factors of a technological, cultural, organizational, physiological and economical type can also influence the ways actions are carried out in collaborative and distributed communities [START_REF] Strauss | Continual Permutations of Actions[END_REF], cited by Fjuk & Dirckinck-Homfeld, 1997). Concerning finer grained external factors, the availability of material resources can influence the way in which collaboration evolves: [START_REF] Scott | Understanding children's interactions in synchronous shared environments[END_REF]. In addition, the control of a resource (e.g. the manipulation of a video) can be determined by the seat one chooses [START_REF] Krafft | Système écrivant et processus de mise en mots dans les rédactions conversationnelles [Writing system and the process of putting into words in conversational writing[END_REF].

The first type of factor (internal) and more specifically, the factors that are internal to the interaction between individuals will retain our attention for the research presented here. In what follows, we apply Baker's model (2002) to two new corpora, gathered in two design situations (a pilot study and a principal experiment), both mediated by computer and at a distance. The dimensions that constitute the forms of cooperative activity (symmetry, accord & alignment) are distinguished according to a methodology adapted to our corpora and from this, we deduce a subset of possible forms of cooperative activity. An analysis of the first corpus identified three factors internal to the interaction between individuals that were correlated with different forms of cooperation in Baker's model. These correlations were tested on the second corpus. In the following sections, we present our methodology, our results and interpretations. Finally, we present our conclusions and our perspectives for this research.

Methodology, analyses and results

In this section we briefly describe our pilot study and show how the results enabled us to form hypotheses about the correlation of specific forms of collaborative activity with three factors internal to interaction between individuals. These hypotheses are tested in the principal study, also described below.

Pilot study

Here, we describe the participants, their prescribed task, the resources they had at their disposal, the experimental protocol, the corpus obtained, the analyses carried out (coding of interactions and determination of forms of cooperative activity), our results and finally our observations and hypotheses.

Participants, task and resources

Six university students, non-experts of origami, but experienced in working on computers, formed the three observed dyads. The participants were asked to compose a procedural text for folding an origami paper hen. They carried out this task on the Internet, each on his or her own computer. The participants did not know each other before the experiment and were asked not to attempt to identify their partner, once they connected. Lack of available computer rooms meant that in reality, participants were all in the same computer room, although they were told they were each connected to a person in another location.

The partners had instructions on paper that they could consult at any time. They also had three tools on their computer screen, two of which are included within DREW (1) (Corbel, Girardot, Jaillot, 2002;[START_REF] Corbel | DREW : Un outil internet pour créer des situations d'apprentissage coopérant [DREW : An internet tool for creating co-operative learning situations[END_REF]. Figure 2 shows: 1. At the top left: a video of the origami folding task that the participants can play at their leisure.

The participants could fast forward, rewind or define a particular time stamp in order to get to any part in the video. 2. At the right: a shared text editor (part of DREW) in which the participants composed their procedural text for folding the origami hen. Both partners could write in the text editor, but not simultaneously, due to single cursor. When one person writes, the other sees the text appear in real time.

At the bottom left: a chat area with a personal text entry zone (also part of DREW). Pressing the

Enter key sends the typewritten text to the shared chat board, thus rendering it visible to ones partner.

Figure 2. The video and two modules of the platform DREW.

Experimental protocol

The pilot study took place in three stages. First, an experimenter explained the task to the participants and described the tools they could use (5 min). Then, the participants were taken into the computer room. While they carried out the task (1h), 3 experimenters observed their actions in order to characterize their activity and to pinpoint any problems. At the end of the experiment, an experimenter interviewed each dyad in order to gather their impressions and to identify any difficulties linked to the resources or the experimental protocol (10-15 min).

Corpus

The participants' computer-mediated interaction via the DREW platform (chat and text editor) was traced and converted from XML into Excel TM format. The chat messages were saved each time the Enter key was pressed after a message was typed. In regards to the text editor, a first level of granularity saved the totality of the text, approximately every second. This was difficult to analyze (cf. Figure 3). A second level of granularity was thus created [START_REF] Dyke | Extension of the Musette framework for synchronous collective activities[END_REF]. Rather than send the entire contents of the text editor to the server, only the modified line (which was given a number) and its state before the modification were saved (cf. Figure 4). A line of text is sent to the server in three cases: 1) when there is no activity in the text editor for more than 5 seconds (= production: timeout), 2) when the participant changes to the chat (= production: speaker changed module) or 3) when ones partner starts composing in the text editor at the same time (= production: speaker was interrupted).

Analyses: two-dimensional coding method

A two-dimensional coding method was elaborated using the chat interventions of the pilot study as an initial corpus. We first determined the pragmatic orientation of the utterance as primarily focusing on one of four categories: the product (the written instructions for the origami hen), social aspects of discourse, the carrying out of the task and the activity (cf. Table 2 for explanations of categories and examples). We then coded each utterance according to the speech act (cf. [START_REF] Austin | How to do things with words[END_REF] that was used: proposition, acceptance, refusal, correction, directive, affirmative, question & response (cf. Table 3). This allowed us to determine the cooperation as a function of the utterance's value. Utterances that have the function of conveying emotions and thoughts of participants, expressions of politeness or any sort of utterance that does not directly concern the task.

"shall we say until our next game?!"

Carrying out the task

The utterances that concern carrying out the task refer to the manner of proceeding, for example the division of roles or procedures or strategies to adopt.

"how do you want to do this, we type here, then in the text area?" Activity Utterances concerning "activity" are used in order to discuss what one or one's "i'm looking at the video" partner is doing or has done. Product Utterances that essentially concern the content of the product (instructions for folding the origami hen) as well as the description of the video.

"then unfold again your sheet of paper you should have your initial sheet"

Determining the form of cooperation

In order to determine the form of cooperation for the different dyads, we used Baker's model of ( 2002), validated for pedagogical situations of cooperative problem resolution. As our situation was of another nature -a design task -we had to find a way to apply this model in our own context. We needed to find a way to characterize the three dimensions used to define forms of cooperation. Symmetry was defined according to two indicators relating to text writing, the principal task: 1) the comparison of the number of interventions in the "textboard" between the participants tells us whether the text writing is equitable; 2) the chat interventions of each participant concerning the text writing also allows us distinguish the transactional role of "proposer" (i.e. does one partner suggest more text proposals?). (Non)-alignment was illustrated by the (presence) absence of phrases of the type "i am lost". Granted, the absence of such phrases does not guarantee alignment: partners could agree to work on different parts of the problem. Also, partners could be aligned, but not have attained a common understanding of their work. The observation grid was also an indicator of alignment: certain partners watched the same part of the video clip at the same time and could thus orient their talk about it. Finally, agreement was decided by coding speech acts: the presence of corrections and refusals determined whether or not the dyad was generally in agreement.

Results

Two of the three dyads were in complete opposition. One of them was in "co-construction": symmetrical (with equal roles), aligned (shared understanding) and in agreement (cf. Figure 5). The other dyad was in "apparent one-sided argumentation": asymmetrical (different roles for each), non-aligned (e.g. lack of shared comprehension) and in disagreement (presence of corrections or refusal of other's utterances) (cf. Figure 6).

Observations and hypotheses

Different observations were made by relating the forms of cooperation used by the dyads and the function of their utterances (cf. Figure 7). We can clearly see that the dyad in co-construction (symmetrical, aligned and in agreement) shows a higher proportion of socially oriented utterances. The correlation of the quantity of socially oriented utterances with good symmetry is thus the first hypothesis we sought to In a similar vein, we observe a higher proposition of utterances concerning carrying out the task for the dyad in construction. Our second hypothesis proposes that this type of utterances is also correlated with good symmetry.

The dyad in apparent one-sided argumentation shows a larger quantity of utterances in regards to activity than the other two dyads. This could indicate that the two actors are trying to align themselves by telling each other what they are doing in order that they may synchronize. Our third hypothesis is thus that the quantity of utterances concerning activity will be correlated to a poor alignment.

Principal experiment

In order to illustrate the differences with the pilot study, we present in the following sections, the participants, the material they used, the task, the experimental protocol, the corpus, the analyses carried out, the results concerning the verification of our hypotheses and finally, our interpretations.

Participants, material, task and experimental protocol

Ten dyads (twenty students aged 20-30 years) participated in the experiment. They were non-experts in origami, regularly used chat and knew how to type on a keyboard.

The material underwent a number of changes from the pilot study. The paper hen was replaced by a paper box, easier to fold in general and with less variation in difficulty. The text editor was also modified in order to allow the two participants to write simultaneously; two cursors instead of one were available. During the pilot study, the presence of one cursor created conflicts that reduced the usage of the text editor to one person at a time. Having two cursors available could favor a more symmetrical cooperation as both partners can write simultaneously (cf. [START_REF] Dyke | Extension of the Musette framework for synchronous collective activities[END_REF]. Otherwise, the platform DREW remained identical with the chat and the text editor as well as the video. Some other modifications were made as a result of problems encountered during the pilot study. After the initial introduction (5min), we added a presentation of the tools and their functions (5min). In addition, a conception micro-task was inserted immediately before the task in order to familiarize the participants with the tools they were to use (10min). The questions were given in questionnaire format in order to avoid influence on the part of the experimenter, but also to obtain information that a participant may not want to divulge in front of his or her partner. (5min). Finally, an individual interview was also conducted (2min).

Corpus, analyses and results

The ten interactions of the ten dyads were automatically recorded by DREW (chat + text editor) and were transformed from XML into Excel TM format (as for the pilot study).

The same coding scheme used in the pilot study was applied to the corpus (on the chat interventions). Then, inter-coder reliability was performed on six of the ten dyadic interactions. Three different coders coded respectively three, two and one of the six interactions, depending on the time they had available. A comparison of these results was done (cf. Table 4) in relation to the original coder, who coded all ten interactions. The average of agreement of the three coders in relation to the original coder was 77.24% for functions and 71,18% for speech acts. As the percentage to be obtained in order for a coding scheme to be reliable is 70%, the coding of both the utterance function and the speech acts is validated [START_REF] De Wever | Content analysis schemes to analyze transcripts of online asynchronous discussion groups: A review[END_REF]. As for the pilot study, and using the same indicators, we were able to identify many forms of cooperation: three dyads in "apparent co-argumentation" (symmetrical, non-aligned, in disagreement), four dyads in "apparent one-sided argumentation" (asymmetrical, non-aligned, in disagreement), two dyads in "co-argumentation (symmetrical, aligned, in disagreement) and one dyad in "one-sided argumentation" (asymmetrical, aligned, in disagreement). The graphs below show (a)symmetry and (dis)agreement and illustrate two examples of the differences between a symmetrical and a asymmetrical dyad. (cf. Figure 8 and Figure 9). Once the forms of cooperation were determined, we calculated 1) the average percentage of the utterances concerning activity according to whether the dyad was aligned or not and 2) the average percentage of the utterances concerning carrying out the task on the one hand and socially oriented utterances on the other according to whether the dyad was symmetrical or not. (cf. Figure 10). In order to ascertain whether the differences between groups were significant, we performed the non-parametric Wilcoxon test, considered to be the equivalent of the t-test.

Firstly, the quantity of socially oriented utterances is twice as large within the interactions of symmetrical dyads than for asymmetrical dyads. The Wilcoxon test shows that this difference is significant and that the two groups are different (Ws=16, p=0.01). Secondly, the quantity of utterances concerning activity is almost twice as large within the interactions of non-aligned dyads than for aligned dyads. The Wilcoxon test shows that this difference is significant and that the two groups are different (Ws=7, p=0.025). Finally, the quantity of utterances concerning carrying out the task did not differ according to dyad symmetry. According to the Wilcoxon test, the two groups are identical (Ws=28, p>0.1).

Percentage of task

Interpretations

Contrary to the data from the pilot study, no dyad was in agreement. We notice much more argumentation on the content of the instructions the students wrote. Perhaps the presence of two cursors in the text editor allowed participants to write what they wanted without first expressing themselves in the chat module and this created disagreement. The presence of one cursor obligates the two participants to reflect together on the content of the instructions before writing them. Viewing a larger number of dyads allowed us to see that being aligned at a distance is rather rare (seven dyads out of ten are not aligned) Not perceiving certain actions of ones partner and not being able to establish eye-contact with him or her does not help in synchronizing reflections and actions.

In regards to the link between (a)symmetry and the quantity of socially oriented utterances (1st hypothesis), it is possible that maintaining good social rapport with ones partner allows for a relation of equality that translates into equitable transactional roles, assuming similar socio-institutional roles. The interactions of symmetrical dyads contain a higher quantity of socially oriented utterances than the interactions of asymmetrical dyads.

However, whatever the form of cooperation, it seems necessary that dyads exchange utterances dealing with carrying out the task. Our 2nd hypothesis is thus not confirmed. There is no link between symmetry and utterances about task. At first glance, this is contrary to the research of [START_REF] Lahti | The nature of collaboration in computer-supported designing[END_REF]. They have found differences in the proportion of the interaction consecrated to the organization of a design task according to group. Indeed, it seems that groups that "collaborate" discuss in greater length the organization of their design than the groups that "cooperate" or simply "coordinate". Their work environment has more modules that allow for more of a difference in task according to group. Certain modules are more pertinent than others in carrying out the task and this leads to choosing amongst them. On the other hand, our own participants only had to organize the use of the textboard and this module is inherent to the writing of the instructions and thus must necessarily be managed.

The link between (non)-alignment and the quantity of utterances concerning activity shows that the lack of information emanating from ones partner concerning his or her activity is compensated for by transmitting this information in writing (chat messages). This was our 3rd hypothesis. When partners are not aligned, it seems they seek to synchronize themselves by expressing what they are doing or by asking what their partner is doing. This is shown by the higher quantity of utterances concerning the activity than partners who are aligned.

Conclusions and perspectives

Our work has enlarged the field of applicability of Baker's model (2002); we have shown it is possible to apply this model with success to computer-mediated interactions whose objective is the design of a procedural text (instructions for origami folding). We have also established a correlation between certain dimensions of this model and three factors internal to dyadic interaction. Firstly, there is a greater quantity of socially oriented utterances in symmetrical interactions than in asymmetrical interactions. Secondly, there is a greater quantity of utterances dealing with activity (e.g. i'm looking at the video) in non-aligned interactions than in aligned interactions. Thirdly, whatever the cooperation type, and considering that all dyads were in disagreement, there is a high quantity of utterances that deal with carrying out the task.

In these two studies (pilot and principal), only the chat messages were analyzed for content. In the near future, we would like to analyze the contributions made to the text editor from two angles: the type of contribution (new production, correction, etc.) and the participant who contributed. This would allow us to refine the notion of symmetry in relation to the whole task. It would also be interesting to relate these observations to the quality of the product in order to appreciate which form of cooperation is optimal.

Endnotes

Figure 4 .

 4 Figure 4. An extract of the interaction (translated from the French) after modification of the trace

Figure 5 .

 5 Figure 5. A dyad in co-construction

Figure 7 .

 7 Figure 7. Percentage of utterances by function of utterance and by dyad

Figure 8 .

 8 Figure 8. Example of a dyad in apparent one-sided argumentation (asymmetrical)

Figure 10 .

 10 Figure 10. Cross between utterance function and the value of Baker's (2002) dimensions of cooperative problem solving: alignment and symmetry

( 1 )

 1 DREW (Dialogical Reasoning Educational Webtool) was designed and developed during the European project SCALE, (Internet-based intelligent tool to Support Collaborative Argumentation-based LEarning in secondary schools, 2001-2004), 5th Framework, IST (Internet Societies Technologies).

Table 2 .

 2 Definitions of the possible functions of an utterance and examples translated from the original French.

	Definition

Table 3 .

 3 Definitions of the speech act categories.

		Definition	Example
	Proposition	Propose, launch a debate on a proposition, either	"the next part : take out the end of the blue corner of
		implicitly or explicitly.	the center of the square that is folded in two and mark
			the fold."
	Acceptance	Show agreement with the utterance of one's partner.	"yeah, that's perfect"
	Refusal	Show disagreement with the utterance of one's partner. "too complicated, don't get it!"
	Correction	something precise or modify a previous	"but I would add the meaning, like: the points that you
		utterance.	just folded outwards…something like that"
	Question	An utterance that shows a request, a search for	"how will you start?"
		understanding or for information, directed at one's
		partner.
	Response	An utterance that gives information in answer to a	"i'm looking at the video" (response to the above
		previous request.	example question)
	Affirmation	Give a piece of information.

"well, most of the work is coming up" Directive Not give the choice to one's partner to either refuse or accept the produced utterance. Give an order or obligate one's partner to carry out an action.

"erase it if you don't like it and write something in its place"

Table 4 .

 4 Inter-coder reliability; Percentage of agreement with the 1 st coder, creator of the coding scheme

		60
		50
	Number of interventions	20 30 40			Dyad in co-construction Dyad in apparent unilateral argumentation
		10
		0
		Social	Activity	Carrying out the	Product
				task

Acknowledgements

We would like to thank Jean-Laurent Cassier, John Bouvery and Magalie Ollagnier-Beldame for their work in carrying out inter-coder reliability.


Abderrahmane Brahmi

David Delmas

Mohamed Habib Essoussi

Famantanantsoa Randimbivololona

Abdellatif Atki
email: aatki@ausy-group.comtmarie@ausy-group.com

Thomas Marie

Thomas Marie Ausy

Formalise to automate: deployment of a

Keywords: design, formalisation, domain-specific languages, compilation, static analysis, formal methods, avionics software, DO-178C, development process, industrial application

come

I. INTRODUCTION

Avionics software running on on-board computers are critical components of the systems of civil aircraft. They are thus subject to certification by Certification Authorities, and developed according to stringent rules imposed by the applicable DO-178/ED-12 [START_REF]C: Software considerations in airborne systems and equipment certification[END_REF] international standard. Among the many processes described in DO-178, verification processes are responsible for more than half of the overall costs of avionics software development. Considering the steady increase in size and complexity of this kind of software, classical V&V processes, based on massive testing campaigns and complementary intellectual reviews and analyses, no longer scale up within reasonable costs.

On the other hand, some formal verification techniques have been shown to cope with real-world industrial software, while improving automation. For a decade, Airbus have therefore been introducing such techniques into the verification processes of some internal avionics software products [START_REF] Souyris | Formal verification of avionics software products[END_REF], in order to replace or complement legacy methods. Significant effort is currently being invested into generalising this approach to most development and verification processes. Nonetheless, the current state of the industrial practice is that completely formal development methods are still not quite tractable for most avionics software products. Therefore, a hybrid approach has been developed to integrate design activities with static analysis, program proof, and testing. The goal is to take maximum advantage from formal methods, i.e., improve industrial cost-efficiency while maintaining the safety and reliability of avionics systems. In this approach, all human-engineered design artefacts are being formalised using dedicated domain specific languages. Internally-developed compilers automate many subsequent development or verification activities, and generate all relevant data for non computable ones, such as verification of correctness. In particular, these compilers bridge the gap from designs to formal verification tools. This approach is made industrial reality thanks to the integration of a set of tightly-coupled tools into a new development workshop supporting advanced dependencies. This workshop, as well as the development process it supports, is currently being deployed on all new avionics software development projects.

This papers aims at describing this process, and supporting workshop. Section II presents the current industrial context, in particular legacy development processes. Section III introduces the new process, with associate industrial objectives. Section IV describes the languages, workshop and tools supporting the new process. Section VI addresses deployment and industrial results. Section V describes related work. Section VII describes future work and concludes. An extended version of this paper, including a running example based on a real-world avionics use case, can be found at http://www.di.ens.fr/ ∼ delmas/erts18/. The workshop presented in this paper is primarily designed to improve the industrial efficiency of software development processes for cockpit avionics systems, such as flyby-wire, warning, communication, and maintenance. Such software is written in C and assembly, and encompass all DO-178 Development Assurance Levels (DAL): fly-by-wire, warning, or communication software are typically certified according to DAL A to C, while maintenance software usually enjoys DAL D or E.

Over the past four decades, most such aircraft functions have been transferred from hardware to software, with increasing requirements on process assurance. This trend, together with the growing effort to optimise passenger comfort, as well as system configurability and interoperability, has resulted in an exponential growth of the size and complexity of this kind of avionics software, as depicted on figure 1.

The state of the industrial practice, on the other hand, has evolved at a much slower rate during the same time frame. Most avionics software processes are still based on informal specifications and designs, pair reviews, and hand-written test procedures based on equivalence class partitioning.

As shown on figure 2, all artefacts produced by development processes, i.e., in DO-178 terminology, High-Level Requirements (HLR), architecture, Low-Level Requirements (LLR), source and executable code, are verified several times. All of them are reviewed for compliance with artefacts from which they are derived on one hand, and for accuracy, consistency, hardware compatibility and conformance to standards on the other hand. In addition, executable code is verified against LLR and HLR by means of unit and integration testing. Test cases and procedures are then also subject to pair reviews. LLR provide very detailed specifications for every individual C function or assembly routine, down to the specification of every single procedure call or volatile access. This specifications are typically expressed in informal pseudocode. In this context, significant effort is invested into unit testing, which roughly amounts to perform grey-box testing of every individual C function or assembly routine on the target hardware, to ensure that it implements the given algorithm correctly. Indeed test scenarios and expected values of outputs are derived completely by hand, from a intellectual reinterpretation of the informal LLR. Then, the correctness of this reinterpretation and the correct implementation of associate scenarios are verified in additional pair reviews.

Despite the automatic compilation of test scripts into target programs for part of the test procedures, the largest part of these heavy design and verification processes is essentially hand-crafted, and relies completely on human expertise. Unfortunately, such legacy processes do not scale up to current avionics software size and complexity within reasonable costs, hence cost issues in both development and maintenance phases. In particular, verification is liable for a steadily growing share of the overall development costs. The current status is about 70%.

To address this economical risk, Airbus have been introducing formal techniques into the verification processes of several internal avionics software products for a decade, in order to replace or complement legacy methods. Such techniques improve automation, while preserving safety. For instance, Some program proof [START_REF] Duprat | Formal verification workbench for airbus avionics software[END_REF] and static analysis [START_REF] Souyris | Computing the worst case execution time of an avionics program by abstract interpretation[END_REF], [START_REF] Delmas | Astrée: from research to industry[END_REF], [START_REF] Miné | Towards an industrial use of sound static analysis for the verification of concurrent embedded avionics software[END_REF], [START_REF] Delmas | Towards an industrial use of fluctuat on safety-critical avionics software[END_REF], [START_REF] Cuoq | Fan-C, a Frama-C plug-in for data flow verification[END_REF] techniques have been introduced here and there on some avionics projects. However, their impact on industrial efficiency has been limited so far by a lack of formalisation of design processes, by an incompatibility of previous testing frameworks with formal methods, and by a lack of interoperation between tools, resulting in significant efforts dedicated to preparing inputs for formal verification processes.

III. ν W oW : OBJECTIVES AND ORIENTATIONS

Airbus is currently investing significant effort into an internal initiative known as New Ways of Working ( ν W oW ), which aims at improving the industrial efficiency of avionics software development processes, while maintaining the highest standards for safety. The major industrial goal of ν W oW is to reduce the cost of design and unit verification processes by 75%.

The way to achieve this ambitious target is to move from hand-crafted legacy processes to an automated process. The ν W oW approach to automation is language-based. Domainspecific languages with well-defined syntax and semantics have been created, to enable the formalisation of all design artifacts. Dedicated compilers have been developed, so as to allow automatic, safe comptuations on explicit, unambiguous design data.

Figures 3 and4 give an overview of the ν W oW automated process. The design phase, presented in the central box, is deeply revisited. In legacy processes, this phase was mostly a preparation for the coding phase, producing informal documentation expressing LLR in the form of pseudo-code, and their traceability to HLR. In the ν W oW approach, the design phase is extended to prepare all unit verification and static analysis activities, as well as part of integration activities:

• the Software Architecture is described in a dedicated domain-specific language, which will be presented in section IV-B. The software is decomposed hierarchically into a set of logical modules featuring both exported interfaces and hidden implementations. Relations between modules are expressed in terms of decomposition and dependency. All programming objects are then introduced and described in this language, and mapped to modules: types, constants, variables, procedures, code and data sections, non-memory mapped hardware registers, special processor instructions (e.g. memory barriers and cache management). This is ex-actly the set of objects to be constrained by LLR. Therefore, the level of description is not only sufficient to enable automatic extraction of source code skeletons to be filled in at coding time or merged with existing code, but also any data relevant to unit verification. For instance, procedure parameters are annotated with their direction (in, out, or both), their passing mode (by value, address or reference), and their class (e.g. arrays passed by reference are annotated with their actual length). Specific instructions expecting an argument (e.g. PowerPC mbar) are described with a function-like interface.

• the LLR are expressed in a first-order logic based language, which will be presented in section IV-C. They describe the observable behaviours of unitary procedures, to be implemented in C or assembly, knowing the annotated interfaces of callees, but not their behaviours. This language is reminiscent of standard Behavioural Interface Description Languages (BISL). Functional requirements on procedure behaviours are formalised as first-order contracts, expressed in terms of preand post-conditions over terms constructed on objects defined as part of the software architecture. In addition, non functional requirements are formalised to automate verification. Indeed the LLR language supports formal descriptions for sequences of calls and volatile accesses, non-standard Application Binary Interfaces (ABI), decomposition of machine words into named fields, (e.g. to model accesses to register fields), and execution of special processor instructions. Moreover, its scope is not limited to DO-178 compliant processes, as it allows for test-driven developments or re-engineering: see IV-C1.

Obviously, a first advantage to such design formalisation is a significant reduction of reviews of design data for accuracy, consistency, or conformance to standards. Nonetheless, the key interest is that it allows for a hybrid approach to unit verification: either unit proof or unit test can be used, as shown on figures 4 and 3. Unit proof is available for C source code, and extremely cost-efficient provided some minimal well-typedness and complexity constraints are satisfied: in this case the proof is automatic. Unit test is available for assembly or less standard C code. Key features for industrial efficiency are:

• all procedures of a given module need not be verified with the same technique; • no change in design data (architecture or LLR) is needed to switch from one technique to another; • most unit verification support data are computed automatically from formalised designs. The only humanengineered inputs are: for unit test: scenarios providing values for input variables. The set of input variables is precomputed for each behaviour from formal LLR. Also, test oracles are first order predicates directly extracted for LLR to be evaluated at run-time. This obviously decreases the necessary effort both in test procedure development and reviews, compared to legacy methods. for unit proof, which will be presented in section IV-D:

1) loop invariants 2) proof tactics for verification conditions that underlying SMT-solvers fail to prove automatically.

Besides, integration testing is alleviated, as some properties that could only be verified in integration tests with legacy processes, e.g. volatile accesses, are verified at unit level, either by proof or by test on virtualized hardware. Moreover, additional process optimisations are obtained in the case of C source code. Reviews for conformance of source code to LLR are eliminated where unit proof is applicable, thanks to the exhaustiveness of this verification technique. Reviews for conformance with the software architecture are automated using a mixture of syntax-based and semantics-based static analysis techniques, such as data flow analysis. Reviews for conformance to standards are automated by syntax-based static analysis tools. Reviews for accuracy and consistency are automated by semanticsbased static analysers by abstract interpretation. Note that the traceability analysis between source and compiled code, usually required for DAL A, is also avoided thanks to the use of a formally verified optimising C compiler: see section IV-G. This process is the outcome of many years of industrial practice. it is made efficient by the tight integration of a number of automated techniques. This integration is orchestrated by a process management tool, which will be presented in section IV-A. For instance:

• the software architecture compiler generates code and documentation, and passes information on to the LLR compiler; • the LLR compiler generates unit proof or test contracts and associate verification environments; • the proof engine is used to check design completeness, even when the implementation is tested; • the LLR compiler generates expected variables ranges and data-flow to be verified by static analysis tools; • functional ranges guaranteed by static analysis enable to focus the scope of unit verification to reachable input ranges; • some static analysers compute configuration files for other static analysers, e.g. a points-to analysis on source code resolves computed calls, which enables a stack analysis on machine code; • static analysis tools validate assumptions or eliminate warnings from design or unit verification tools.

As a consequence, code and design reviews are mostly limited to tool warning analyses.

In addition, this tight integration allows for significant savings in tool qualification costs. Indeed, DO-178 compliant qualification strategies typically require the definition of a set of user contexts for which given tool is qualified. This context includes many user-specific tool parameterisations, but also requirements on the machine on which the tool may be run, e.g. processor, operating system, libraries, etc. In practice, this approach leads, in legacy processes, to a combinatorial explosion of the number of contexts to be documented and maintained. All qualification procedures, many of which are at least partially hand-crafted, are to be replayed in all candidate contexts. Strong requirement on host machine environments limits the set of machines on which tools may be run, and result either in the need to maintain or virtualize obsolete systems for legacy projects, or to invest in costly migrations. In the ν W oW , tool qualifications are also managed by the same process management tool as developement and verification artefacts. As consequence, the ν W oW process can be deployed over a cloud of heterogeneous machines. Whenever an operational process requires the use of qualified tool with a given set of options on a given machine, the process manager detects whether the tool is already qualified for this context, and launches qualification tests automatically for this context if it is not the case.

IV. ν W oW : IMPLEMENTATION Figure 5 provides a high-level data-flow view on how the ν W oW process is implemented on a given avionics project. The ν W oW process has three tool-supported processes:

1) the design process; 2) the coding and static analysis process; 3) the unit verification process. The CoDDA IDE interacts with companion design compilers coddac and dcslc through Optimases, the process automation tool. In particular, coddac computes a database from CoDDA files, aka dictionary, as depicted on figure 5. This dictionary describes all design objects, as well as relationships between them. This information is the primary input for Optimases, the process automation tool. Indeed the database contains all the dependency information that is necessary to instantiate the process for the target project. As a consequence, Optimases bootstraps itself to construct the whole project dependency tree from the design dictionary. As part of the design process, Optimases interoperates coddac and dcslc to generate source code templates and headers, check for design rules dependant on both architecture and LLR, as well as to produce data flow specifications.

As part of the coding and static analysis process (blue boxes of figure 5), auto-generated code templates are filled in by programmers to produce C or assembly implementations, and compiled via a build process. Optimases triggers verification processes for coding standard conformance (CheckC), absence of run-time errors (ASTR ÉE), correctness of data flow with respect to specifications (Fan-C), compliance with the Software Architecture (Cascada), and absence of stack overflow (StackAnalyzer).

As part of the unit verification process (violet boxes of figure 5), Optimases supports a hybrid approach to verification of implementations against LLR, either by proof or by test. Inputs of unit proofs are source files and hand-crafted loop invariants. Inputs of unit tests are compiled sources and test vectors. The coverage of verification is ensured by a (yellow) "mixability" configuration file: for every source file, every function or procedure is either proved correct, or tested according to the applicable structural coverage criterion.

More details on sub-processes and supporting tools will be provided in the next subsections.

A. Optimases

Optimases is both an process management tool and a build system.

A process management tool: Optimases allows to configure complex processes easily. A process is fully defined in XML collections. It can be easily updated by adding/removing tool(s), fixing issue, or inserting new collection. Even if XML is not the most human readable format it allows to ensure the well formatted collection through XML scheme (xsd file) and offers the way to extract automatically some smart information about process (Tool dependency, collection's process view, full avionic process view...) using xslt sheet. The Optimases configuration is based on:

• file's type: File are all typed using pattern definition.

• tool definition: Allow to link inputs to outputs (based on type definition). • variables use: Variable are mainly required for genericity goals. They allow to manage several level of configuration (workshop, project). • template definition: Templates provide the way to program complex process (with several step between user's sources and result). The user has just to apply this template with their inputs regardless the intermediate state.

• variants definition: A variant allows to derivate main process in an other context (debug, coverage).

A build system: Optimases is inspired by tup [40], though constraints on the definition of build rules are less strict:

• use of a database to manage its dependency tree.

• explicit dependencies specified by user.

• implicit dependencies detection using file access detection (libfuse [32]).

In addition, we have added some useful features:

• the dependency arrows go both up and down (make uses down, tup uses up).

• File freshness detection based on SHA1. Decrease the build action by stopping the process as soon as a built action has no effect on this output. • The Optimases build directory can be fully outsourced, so Optimases can be seen as distributed process tool management.

Optimases in ν W oW : Optimases (and this collections package) is the conductor of then ν W oW . It makes a complex process easy to use for developers. Once the main process is defined, it allows to configure specific cases without effort. For instance, the unit test of functions calling inline functions requires automatic prototype adaptations. Also, the automaticity of unit proofs of functions accessing volatile locations is optimised dynamically, chosing the most efficient instrumentation mode from design information computed by the dcslc.

Optimases provides also an alternative debug variant (derived from the main process). This variant is not relevant to certification, but critical for productivity (decrease of investigation time). It is fully automatised. If one Optimases step failed, the developer can replay it in debug mode and investigate. Optimases provides for instance:

• Object/binary compiled with debug information.

• Automatic debug script (break point on error) for unitary test. • Launch debug GUI (Interactive Proof Editor or GDB client for test on a virtual platform).

At user level, Optimases allows to have the whole LLR process automatically computed and so already up to date, following the project's design upgrade.

B. Codda 1) Introduction:

CoDDA (Compilable Design Description Assistant) is a framework implementing the method of software static design by abstract machines. This method is an adaptation of the HOOD [START_REF] Rosen | HOOD: An Industrial Approach for Software Design[END_REF] method to the avionics development context.

CoDDA provides a domain-specific language with a well-defined syntax and a set of functionalities, such as automatic generation of code skeletons and design documentation, design consistency verification.

2) The CoDDA Language: The CoDDA language (CoDDAL) enables designers to formalise the descriptions of so-called machines (a.k.a modules) featuring exported interfaces and hidden implementations. So-called non-terminal machines describe in fact only interfaces for other machines to use. Non-terminal machines are refined into children machines, until so-called terminal implementable machines are reached. Elementary design objects are named types, constants, resources and services. CoDDAL is supported by a dedicated, internally developed compiler.

3) CoDDA IDE: CoDDAL is supported by an IDE providing indentation, syntax highlighting, cross navigation between references and their declarations (CoDDA, DCSL and C), graphical interface to CoDDA functionnalities (e.g. code skeletons generation), snippets and a relevant autocompletion. Auto-completion is implemented by using a database (the dictionnary) in the back-end generated and updated by the Optimases processes.

4)

CoDDA Checker: The CoDDA Checker is integreted into the development process to ensure that a set of rules is met by the static design of the software.

For instance, the Checker warns if a machine declares a service in its exported interface, but no other machine uses this service.

5)

CoDDA in the ν W oW : Software Architecture: Based on a well defined static design of a software, derived from the HLR, CoDDA provides major activites (or features) part of the ν W oW process.

The CoDDA compiler ensures the correctness of the static design w.r.t. the CoDDAL syntax, and computes the Abstract Syntax Tree (AST). This latter is used by the CoDDA compiler in order to:

• generate the dictionnary (a.k.a database) with all the objects of the static design. This dictionnay has a very important place in the whole ν W oW process and its activites. For example, Optimases uses the dictionnary to manage the dependencies between services and their implementing modules. Which is relevant in order to enable DCSL contract compilation or unit proof. • automatically generate header and include files used by DCSL compiler, unit verification and code compilation. For example, ranges of bitfields are defined in the static design and used in the DCSL. Header files generated by CoDDA make them visible to the DCSL compiler. Skeletons of source code files imported and filled in by the user at coding time are also generated and can be automatically pre-filled with elements from DCSL contracts. These skeletons can also be automatically merged with exsiting code. • generate the traceability report from the static design: Specific keywords and rubric are used by the user in order to link design elements to the HLR. The report combined with the one extracted from DCSL conracts is used by dedicated tools part of the ν W oW process to check if all the design elements and detailed design behaviors are all traced and covered by the High Level Requirements. • verify the coherence of the code w.r.t. the design. Note that, only elements of the code which represent objects of the design are verified, such as resources, types, services signatures, etc. The main inputs are:

• CoDDA files: a CoDDA file can represent either the main machine, a terminal machine, or a non termial machine describred in CoDDAL. • pre-code files: designers may provide coding hints for a service, to be included into code skeletons. • dcsl files: DCSL contracts for services;

• traceability keywords: the set of keywords (e.g. #Link To) to be used to identify traceability information in the design. The main outputs of CoDDA are:

• code skeletons • design documentation (HTML or PDF)

• traceability report • design database: persistence of all entities and elements of the static design. This is the dictionnary mentionned in different sections of this paper. • checker report: used in the derogation phase (the user can give justifications of warnings). After the verification phase, Optimases gives a synthesis of all justified and unjustified warnings. • merged code: user code merged with freshly generated skeletons.Whether or not merged source code files are imported to replace previously developed code is left for the user to decide.

7) The Application Binary Interface (ABI):

In real-world industrial software, performance and hardware constraints may require developping software functions (a.k.a services) which do not meet standard ABIs. For example, contexts of callers may have to be managed in an environment which does not handle call stacks nor memory accesses. Other functions may require a change of privilege or specific calling conventions. For these reasons, as part of CoDDA specific ABIs can be defined in the satic design in order to specify:

• registers used in the calling convention between the caller and the callee: which registers are used for which function parameters and how values are returned and retrieved.

• how formal parameters are allocated.

• the calling sequence of the caller and the returns sequence of the callee.

This allows the user to make abstraction of these particularities and homogenize the use of functions during the design or test activities.

C. DCSL 1) The language:

Design-Contract-Specification-Language, DCSL, is the notation that has been coined to formally support the detailed design of embedded-software units. It is essentially a code-level behavioral interface specification language [START_REF] Hatcliff | Behavioral Interface Specification Languages[END_REF] where the functional behaviors are expressed in terms of precondition/postcondition in the language of a many-sorted first-order logic. It is a well-established [START_REF] Floyd | Assigning Meaning to Programs[END_REF], [START_REF] Charles | An Axiomatic Basis for Computer Programming[END_REF], [START_REF] Charles | Proof of correctness of data representations[END_REF], [START_REF] Meyer | Applying "Design by Contract[END_REF] approach shared by all code-level BISL's among whilst ACSL [START_REF] Baudin | ACSL: ANSI/ISO C Specification Language -Version 1[END_REF], JML [START_REF] Gary | JML Reference Manual[END_REF], CodeContracts [START_REF] Logozzo | Code Contract User Manual[END_REF] or SPARK2014 [START_REF]SPARK 2014 Reference Manual[END_REF].

However, DCSL has native extensions, additions and restricted language features so as to provide an orthogonal support for the detailed design of diverse embeddedsoftware:

• the programmig language may be C or assembly, A comprehensive presentation of the entire language is out of the scope of this paper. Instead, a running example available at http://www.di.ens.fr/ ∼ delmas/erts18/ gives a concrete illustration of the solutions that have been chosen and implemented.

•
A DCSL specification program consists of two successive parts, the second of which is optional:

1) The design of the interfaces. The specification of the interfaces (types, variables, functions) uses C99 as its core language. In addition, native DCSL constructs are provided and may be used, as required, for the specification of specific hardware resources (e.g. non-memory-mapped registers), for the specification of specific attributes of hardware resources (read-toclear, address constraints, . . . ), for the specification of design-level attributes (mode and direction of a formal parameter, noreturn function, range of values, . . . ). of program actions: calling a function, calling a function with specified values for parameters, reading a (volatile) variable, writing a (volatile) variable with a specified value. It is worth noting that formulas must be run-time evaluable. The quantifiers are restricted to finite integer intervals for the first-order formulas.

And the temporal operators are restricted to finite event-counts (no "eventually", or "always" operators) for the finite temporal sequences formulas. b) Tests. Tests are made-up of test cases. Test cases are formally models (valuations of the free variables) of the contracts formulas. The set of the test cases is accepted as a "sufficient" characterisation of the program unit (DAL-sensitive consensus approved by all actors). In that sense, when both contracts and tests are present, they are specifications of the program unit.

2) Designing with DCSL and its compiler: In the context of the ν W oW , the very first input when designing with DCSL is a CoDDA-pre-generated DCSL program which contains the design of the interfaces. Additional higher level specifications may be used by the designer to fully develop the formulas of the contracts. The DCSL compiler frontend parses and analyses the DCSL program. It detects any compile-time semantic errors and warns about some possible run-time semantic errors. If no semantic error is detected, the back-end generators can be activated. No generation action is run on an incorrect DCSL program.

Design input data

DCSL design (contracts)

DCSL compiler

The design of the tests requires two DCSL design steps. The first step is the design of the contracts as formerly described. From this correct input, the compiler is run in a mode which will generate a DCSL program extended with templated tests. The identification of the formulas and the free variables that contribute to the tests is an intrinsic part of the generation. It make use of a dedicated semantic analysis guided by methodological rules. Thus the design of tests is the design of the models of the formulas, that is the design of the set of values to be substituted to the template placeholders, thus yielding the DCSL design with tests. 3) Compile for proof: The downstream unit proof process expects a set of ACSL formal annotations for its inputs. In legacy processes already including some proof techniques, such annotations were completely hand-crafted. In the context of the ν W oW , they are produced automatically by the DCSL compiler from a semantically correct DCSL program. No further action of the designer is needed for the unit proof.

D. Unit proof

Since a decade, program proof techniques have been successfully introduced to replace unit testing on some software subsets, where the Caveat tool is used for certification credit [START_REF] Duprat | Formal verification workbench for airbus avionics software[END_REF] This obsolete tool is currently being replaced by the WP plugin of the Frama-C [START_REF]The Frama-C framework for analysis of C code[END_REF] platform.

Unit proof as part of the ν W oW stands for the restriction of program proof to the scope of an individual C function, along with a dedicated environment featuring stubs for callees and instrumentation of volatile accesses.

The implementation of a given C function is verified against a formal ACSL [5] contract, computed from its formal LLR by the DCSL compiler. The proof is conducted semi-automatically within a deductive system based on Hoare Logic [START_REF] Hoare | Viewpoint -retrospective: an axiomatic basis for computer programming[END_REF] and Dijkistra's Weakest Precondition Calculus [START_REF] Edsger | Guarded commands, nondeterminacy and formal derivation of programs[END_REF]. Throughout a proof campaign, bundles of proof obligations are generated by Frama-C/WP, and submitted to the Alt-Ergo [4] SMT-solver [START_REF] Sylvain Conchon | CC(X): Semantical combination of congruence closure with solvable theories[END_REF] (c.f Figure 7). In the overwhelming majority of cases, proof is conducted fully automatically. Targeted rate exceeds 95% of entirety of goals. Nonetheless, proof engineers may terminate interactively some proof obligations by means of the Interactive Proof Editor. Complex goals generated by WP may then be decomposed into smaller pieces by applying several tactics available through the user interface. These tactics are saved and put ot use automatically in the following proof campaigns. Proof engineers provide also loop invariants.

In addition, the proof engine checks the completeness of the LLR, in that it ensures every possible pre-state or the function is captured by at least one ACSL (hence DCSL) behaviour. The reader may refer to a long version of this paper at http://www.di.ens.fr/ ∼ delmas/erts18/ for details on the automatically generated proof environment, in particular stubs for callees, and instrumentation of volatile accesses. It contains also information on the semi-automatic management of loop invariants. 3) Practical implementation: To reach this abstraction level for types of applications, in particular low-level applications, unit tests are run on the SIMUGENE representative virtual platform. The DCSL compiler generates calls to a dedicated run-time library, which cooperates with SIMU-GENE's fault injection module [START_REF] Brahmi | Final integration test of avionic software in full virtual platform[END_REF], which handles: volatile variables The injection module is configured to both 1) collect all information on write accesses to volatiles, e.g. written values, access numbers, etc.; 2) inject user-defined values on read accesses to volatiles. Hardware registers to prevent side-effects during the initialisation or capture of hardware registers, the injection module is used ton ensure that registers may be safely used in the prologue of the procedure under test, and captured at epilogue, even in case of abrupt exit. Management of non EABI routines In this case, a specific, non standard ABI is formalised to describe the call protocol of the routine -at entry and exit, the registers allocated to formal parameters and return codes, the volatile or non volatile nature of each register. The DCSL compiler generates calls to the fault injection module, so the tester does not need to do it. From the designer and test point of view, such non EABI routines are thus handled like simple C functions, with typed formal parameters and return value. Special microprocessor instructions Some DCSL contracts described sequences of special processor instructions. The injection module allows the user to view them as standard functions, for which calls, inputs and outputs are to be monitored.

All theses commandes and interactions are run without altering or instrumenting the software under test.

To improve the efficiency of the error detection and fix, a GDB script containing a breakpoint on every erroneous precondition and postcondition is generated automatically. Thus, a simple Optimases command lets the user relaunch a test scenario in debug mode. The test then stops on every error, and the GUI display the falsified predicate. the debug session may then continue either at DCSL contract level, or at the level of the C source files generated by the DCSL compiler, or at the level of the embedded software under test.

F. Static analysis

The formal verification of non-functional properties requires semantics-based automatic analyses that scale up to very large programs. As a consequence, static analysis based on abstract interpretation [START_REF] Cousot | Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints[END_REF] is currently used industrially for certification credit on many avionics software products developed at Airbus, to compute safe upper-bounds of stack consumption with AbsInt StackAnalyzer, or worst-case execution time [START_REF] Souyris | Computing the worst case execution time of an avionics program by abstract interpretation[END_REF], with AbsInt aiT WCET, or to verify data and control flows at unit level with the Fan-C [START_REF] Cuoq | Fan-C, a Frama-C plug-in for data flow verification[END_REF] tool. Moreover, the ASTR ÉE [START_REF] Bertrane | Static Analysis and Verification of Aerospace Software by Abstract Interpretation[END_REF] abstract interpretation based static analyser is being used industrially at Airbus, prior to certification, to prove the absence of run-time errors on safety-critical synchronous control/command programs [START_REF] Delmas | Astrée: from research to industry[END_REF] written in C. It has also be been shown to be mature for use on a large set of asynchronous, multithread avionics applications [START_REF] Miné | Towards an industrial use of sound static analysis for the verification of concurrent embedded avionics software[END_REF]. The FLUCTUAT static analyser has also been shown to be industrially usable to evaluate the numerical accuracy of floating-point libraries of control programs [START_REF] Delmas | Towards an industrial use of fluctuat on safety-critical avionics software[END_REF], and is in the process of being transferred to operational developers.

In addition to these semantics-based static analysers, an internal syntax-based rule checker [START_REF] Delmas | Taster, a frama-c plug-in to enforce coding standards[END_REF] named CheckC is used to check C code for conformace with coding standards.

All these static analysers are integrated as part of the ν W oW , where they play a critical role.

G. Certified compilation

After extensive experiments [START_REF] Bedin Franca | Towards formally verified optimizing compilation in flight control software[END_REF], [START_REF] Bedin Franca | Formally verified optimizing compilation in ACG-based flight control software[END_REF], the CompCert [31], [START_REF] Boldo | Verified compilation of floating-point computations[END_REF] formally verified compiler is currently being transferred to operational projects, to allow optimising compilation of DAL A software, while guaranteeing semantic preservation between source and compiled code. This guarantee enlarges the scope of sound source code analysers to also achieve verification objectives that traditionally require testing, or machine code analysis [START_REF]formal methods supplement to do-178c and do-278a[END_REF].

V. RELATED WORK

Our approach to design by contracts is inspired by JML [START_REF] Gary | Preliminary design of jml: A behavioral interface specification language for java[END_REF], and Microsoft research's CodeContracts [START_REF] Logozzo | Practical specification and verification with code contracts[END_REF]. However, we target C and assembly. Our hybrid approach to verification, combining testing, static analysis and program proof is similar to that of the Hi-Lite project [START_REF] Kanig | Hi-lite: the convergence of compiler technology and program verification[END_REF], supported by AdaCore and CEA. We did not look into using SPARK, as Ada is not used on the avionics software products we develop. We could have considered e-ACSL, but we had already developed the internal TCSL solution on previous projects, so that it meets our needs exactly. Our use of domain-specific languages to improve productivity is related to Galois's endeavour [START_REF] Patrick | Building embedded systems with embedded dsls[END_REF], though we focus on automating the production of design and verification artefacts, rather the final product itself. Like in DARPA's HACMS project [START_REF] Fisher | Using formal methods to enable more secure vehicles: Darpa's hacms program[END_REF], we rely on domain-specific languages, formal verification, and certified compilation, though our main focus is correctness and safety rather than security.

VI. DEPLOYMENT AND RESULTS

the ν W oW process and supporting development and verification workshop is currently deployed on two mediumsized development projects. No definite productivity measures have been established as of today, but there are strong indications of a significant improvement for the subprocess concerned with design and unit verification. Indeed, as demonstrated on a small (but real-life) running example available at http://www.di.ens.fr/ ∼ delmas/erts18/, about 80% of the design, code, and unit verification data is generated generated completely automatically by the design workshop. In addition, about 90% of the implementation can be verified by means of unit proof, and about 90% of the proofs are automatic (after loop invariant definition). In the case of unit testing, the level of automation is also tremendously improved versus legacy processes. Finally, for both verification techniques, the integration of advanced debug facilities to the development workshop yields key productivity enhancements. Therefore, wer are very confident to reach a productivity gain of 50% on the design and unit verification phases for these projects.

VII. CONCLUSION AND FUTURE WORK

In this paper, we describe a development process integrating tightly formalised designs, static analysis, program proof, and testing. This process is supported by a workshop based on an internal process management tool maintaining dependency information between all development and verification artefacts, and allowing for contextual, automatic, dynamic adaptation of the verification process, and assisted transitions between development phases. This process, and supporting methods, tools and workshop, are intended to be deployed in all new projects. The next step is the deployment of the ν W oW on two large-size redesign projects: that of the Airbus Single-Aisle Flight Warning Computer, and that of ATR Multi-Function Computer. Some legacy projects are also considering migrating. This hybrid process allows for the efficient cooperation of heterogeneous but complementary approaches to avionics software engineering. Up to now, it seems to keep its promise: allow for large improvements in cost-efficiency, while preserving the quality of avionics software.

However, the initial industrial target, which is to reduce the cost of design and unit verification processes by 75%, is not meat yet. Extensions of the ν W oW are necessary to address residual shortcomings, and reach this target. For instance, unit tesing methods could be reduced to functional ranges, provided sound static analysis guarantees no value is reachable outside these ranges. Limited extensions of the contents of design data could enable for the automatic generation of link scripts, and the automatic verification of memory mappings. Template loop invariants could be pregenerated to save time in the unit proof phase. Specific proof tactics could be integrated to further improve unit proof automation in a given context. Some preconditions on procedures still need to be validated in reviews. They could be validated by static analysis. Finally, static analysis could be used to check the consistency of test scenarios.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Airbus avionics software (MB)

Fig. 3 .Fig. 4 .

 34 Fig. 3. ν W oW process with unit test

Fig. 5 .

 5 Fig. 5. Optimases for process management In the design process (cyan boxes of figure 5), developers formalise the Software Architecture and associate LLR using the IDE of the CoDDA tool -see IV-B3. The output is a set of CoDDA files describing the Software Architecture, and a set of DCSL files describing LLR.

Fig. 6 . 6 )

 66 Fig. 6. Summary of CoDDA interface

  the software assurance levels (DAL) range from lifecritical (DO178 level A) downto weakly-safety-related (DO178 level E), • software types range from low-level software running on bare-hardware to application software running on top of a multi-application multi-threaded embedded-OS platform, • the unit verification may use formal proof, test, or a mixed proof-and-test, • the development may use the classical-V, specificationdriven process or may adopt the emerging test-driven process, • the engineering program may be a new development or a ν W oW rehosting of a mature (aka legacy) software.

2 )

 2 The design of the behaviors. The specification of the dynamic behaviors uses native DCSL constructs. It consists of two parts, none of which is mandatory. a) Contracts. Contracts are made-up of precondition/postcondition properties. The properties are logical formulas. The formulas are many-sorted first-order logic whose sorts and base terms are -essentially -the types and variables of the program. But some properties of interest, data and control flows, hardware resources handlings, are expressed as formulas in a native DCSL construct for finite temporal sequences, whose events are the observable occurences

  Design input data DCSL design (contracts{; tests}) DCSL design (contracts; test templates) DCSL compiler

4 )

 4 Compile for test: The downstream unit test process expects a set of C programs and declarations for its inputs. In legacy processes, such inputs were completely handcrafted. In the context of the ν W oW , they will are produced automatically by the DCSL compiler from a semantically correct DCSL program. No further action of the designer is needed for the unit DCSL design (contracts; tests) DCSL compiler Test prog.c Test env.c Test stubs.c Test consts.h Test stubs.h

Fig. 7 .

 7 Fig. 7. Unit proof environment

E. Unit test 1 )

 1 Tests design vs implementation: The use of toolssupported formal methods all along with the automatization of the processes has enabled to separate the design of the tests from the implementation of the tests. The implementation of the tests with the tricky and error-prone activities is now totally tools-supported. The tester is focused solely on the design of the tests: design data sets which are models of the logical formulas at the prestate of the unit-undertest. He has no longer to develop test programs, simulated environments, test oracles, specific interfaces for assembly programs nor to manage test runs on specific-hardware testplatforms. All of these error-prone, full of tricky technical details activities are now totally handled by tools (DCSL compiler, Optimases, SIMUGENE).

2 )

 2 Process: Figure 8 introduces the unit test process supported by Optimases. Testers fill in test templates computed by the DCSL compiler with input vectors. the rest of the process is automatic.

Fig. 8 .

 8 Fig. 8. Unit Test environment

Development activity Review or analysis Integration Testing Test activity Reading Reading 27/06/2016 Reading Reading Reading Unit Testing Reading Reading Reading = Reduced activity Static Analysis (almost) automatic analysis

  S.A.S. All rights reserved. Confidential and proprietary document.

	W Presentation-27th June 2016
	System
	Requirements
	High-level
	Requirements
	Software	Formal Low-level
	Architecture	Requirements
	C Source
	code
	Executable
	Object code

s

  • checker rules: the list of rules to activate when calling the CoDDA Checker. See IV-B4. • DCSL compilation reports: for tasks as the generation of traceability report or for the CoDDA Checker, CoDDA needs information from the detailed design (in DCSL, see IV-C). This information is given as input to CoDDA and is provided by the DCSL Compiler. The consistency of the dependencies between the different tools (CoDDA Compiler and DCSL Compiler in this case) is ensured by Optimases. • user code files: previous source code to be merged with updated CoDDA generated skeletons.

  ASTR ÉE computes the set of functions reachable by any computed call, and generates the associate configuration file for StackAnalyzer; 5) FLUCTUAT proves round-off errors are small enough to rely on a real-valued semantics when proving C functions performing floating-point computations; 6) the coding rule checker limitates the subset of C that the programmer can use, which increases the automation of both semantics-based static analysis and unit proof.

	Indeed
	1) data flow specifications to be verified by Fan-C are
	computed by the DCSL compiler on formal LLR;
	2) CoDDA, DCSL and Optimases generate inputs for the
	run-time error analysis, such as the ABI configuration,
	the set of inputs with their ranges, and expected ranges
	on outputs;
	3) ASTR ÉE validates strong assumptions used by Frama-
	C/WP to optimise proof automation (validity and sep-
	aration of external pointers, absence of overflows in
	arithmetics or conversion), or similar implicit assump-
	tions of unit tests;
	4)