Bruce Lewis

The SAE Architecture Analysis & Design Language (AADL) A Standard for Engineering Performance Critical Systems

Keywords: Architecture, Computer Architecture, Model Based Development, Architecture Design Language, Computer System Engineering, Computer Modelling, AADL, Architecture Analysis &

The Society of Automotive Engineers (SAE) Architecture Analysis & Design Language, AS5506, provides a means for the formal specification of the hardware and software architecture of embedded computer systems and system of systems. It was designed to support a full Model Based Development lifecycle including system specification, analysis, system tuning, integration, and upgrade over the lifecycle. It was designed to support the integration of multiple forms of analyses and to be extensible in a standard way for additional analysis approaches. A system can be automatically integrated from AADL models when fully specified and when source code is provided for the software components. Analysis of large complex systems has been demonstrated in the avionics domain.

Introduction

As computer based systems have become more complex and as we continue to exploit the benefits of code generation for components, the problem has become the integration of components. It's not enough to have correct code for the software components or subsystems, they must be properly integrated and correctly executed to have a fully functional system that meets its performance critical requirements. The problem is multi-dimensional because the system performance qualities that must be achieved are highly cross coupled. For example, the change to a software component or the substitution of another hardware component can affect system latency, safety, fault tolerance, bus utilization, processor utilization, etc. And failure to meet the performance critical qualities required results in failure of the system just as surely as a functional component's failure to provide the right output or an algorithm's failure to control adequately. Yet, we as an industry had not developed a sufficient system engineering approach for these computer systems, preferring instead to test and simulate, or to over specify resources. But the end result has been that system integration for complex embedded or performance critical computer systems is one of the highest areas of program risk. It's also a major cost driver on programs that do succeed and integration issues have a major impact on the cost of upgrading.

A model based approach, where the models we use to analyse the system are the models that will drive its execution and communication provides a much more predictable and powerful approach. In such an approach designers engineer rather than populate with rough estimates and testing. As Dr. Eric Conquet of the European Space Agency and Director of ASSERT stated in a presentation [START_REF] Conquet | ASSERT -Automated proofbased System and Software Engineering for Real-Time systems[END_REF], "Software crisis: origin is in fact a lack in system engineering " and "Use of formal techniques at the software level without any formal approach at system level is a nonsense".

The Virtual Panel for this conference also recognizes the importance of modelling in embedded systems as stated by Jean-Claude Aloconque, "The most significant developments are definitely the increase of processor performance followed by the drop in the chip's cost, followed by the evolution in standalone systems toward distributed and interconnected systems and finally the use of modelling".

As an industry, to meet this need to precisely specify and model embedded performance critical systems, we must have a common standard language with strong semantics that can capture both the structure and dynamics of embedded systems. It must support the capture of properties of these systems and the analysis approaches to evaluate the critical qualities. It must be incremental to support all lifecycle phases from early abstraction to final implementation.

Since our analysis approaches will differ and grow, we need a language that is also extensible in a controlled fashion to preserve the benefits of a standard, but also provide flexibility. The AADL was developed for just such a purpose. It was developed from significant experimentation and research over 15 years. It provides a language that is useful across domains where real-time, embedded, fault tolerant, secure, safety critical, software intensive systems are developed. Its natural fields of application include avionics, automotive, autonomous systems, industrial, medical, etc.

Standard Development

History

The AADL language has been formed from three major areas. The proof of concept and base for its development was the MetaH language. Metah was developed by Honeywell Labs, with Dr. Steve Vestal as principle investigator, over 12 years and three DARPA programs [START_REF] Binns | Domain Specific Software Architectures for Guidance, Navigation and Control[END_REF]. It was used in over 40 experimental projects, many of them DARPA programs, internal Honeywell investigations, Army experiments and/or SEI experiments. From these experiments in multiple domains of application, but primarily avionics and flight control, over 30 improvements were defined for the next generation language.

Several of these projects were performed in our lab, one being the development of a reference architecture for missile systems and re-engineering a missile system to that architecture, building it and the 6DOF real-time simulation it flew in, software-in-theloop, with MetaH and the MetaH toolset, including specification, analysis and automated system integration [START_REF] Mcconnell | Reengineering a Single Threaded Embedded Missile application onto a Parallel Processing Platform using MetaH[END_REF][START_REF] Kruger | Fitting The Pieces Together: System/Software Analysis and Code Integration Using MetaH[END_REF]. Significant cost savings were obtained and system and component changes were rapid and efficient including hardware upgrades, system partitioning, component partitioning and upgrades, rate changes etc. Several involved rapid development of components via Matlab/Simulink with Beacon code generation and rapid integration, to a MetaH specified system architecture, onto the embedded hardware using the MetaH toolset. These experiments and the proprietary nature of MetaH convinced the author that an open Architecture Description Language standard supporting model based development of embedded systems was needed and was worth pursuing.

The second major area of input to the language was the other ADL languages developed by DARPA and within industry. See figure 1. Experience with these languages and MetaH, especially at the SEI by Dr. Peter Feiler, were also leveraged in the design of the AADL which broadened the domain of application and helped form the core AADL from which extensions would be later developed. Expertise on the standardization committee with UML and HOOD/STOOD were also leveraged to validate concepts, provide an industrial strength solution and ease integration within the industry. Coordination began with the Object Management Group over 3 years ago to develop a standard AADL Unified Modeling Language (UML) profile to provide the benefits of AADL to the UML community. The standardization of this profile is being done in partnership with the UML community. The third major area of input was the SAE committee (see figure 2) which developed the requirements document, the core standard AS5506, and the annexes to the standard. Many language features were formed from the expressed needs of industy representatives from many of the major aviation and real time systems companies in the US and Europe. Many of the participants are leading engineers in their companies developing the next generation approaches for computer system development. These engineers recognized early the need for a common standard ADL to support computer system engineering in performance critical systems.

Boeing, Raytheon, and Smith Industries are currently not voting members but were major contributers during the development of the standard. Note the number of European participants in the standard. Automotive participants are new to the committee but because of their interest and others in the industry who do not attend, the AADL will become a joint standard of the SAE's Aviation and Automotive divisions.

Coordination with research programs and other standardization bodies are welcome, as well as new member companies. The SAE standard is being coordinated with North Atlantic Treaty Organization (NATO). NATO is also applying the AADL along with the US Air Force and another SAE committee, AS1, to develop approaches for rapid weapon system integration [START_REF] Gregory | Aircraft, Launcher & Weapon Ineroperability -Review of Technical Findings[END_REF][START_REF] Windisch | AADL-Modelling of Plug&Play Weapon System Architecture[END_REF][START_REF] Lacerte | AADL and MDA -Early Experience Applied to Aircraft-Weapon Integration[END_REF]. The AADL will be part of the OMG UML MARTE profile and the AADL committee has members on the MARTE committee. Research projects in Europe have sigificantly contributed to the standard, and are expected to continue to do so. COTRE [START_REF] Farail | COTRE a Software Design Workshop[END_REF][START_REF] Gaufillet | COTRE as an AADL profile[END_REF] and TOPCASED [START_REF] Gaufillet | TOPCASED -Toolkit In Open source for Critical Applications & SystEms Development[END_REF] are two Airbus led programs that have worked closely with the committee. The ASSERT [START_REF] Conquet | ASSERT -Automated proofbased System and Software Engineering for Real-Time systems[END_REF] program, European Union funded and European Space Agency led, is also working closely with the committee. These programs are applying the language, extending the language through annexes and developing tools.

Current State

The core AADL standard [11], version 1.0 was published in Nov. of 2004. We expect to put out a new version with errata changes and the balloted annexes in the spring of 2005. This will be the version that will be a joint standard between the SAE Aviation and Automotive Divisions. Below are listed the current approved annexes [START_REF]SAE Architecture Analysis & Design Language (AADL) Annex Volume 1 : Graphical AADL Notation, AADL Meta-Model and Interchange Formats, Language Compliance and Application Program Interface[END_REF] and two of the annexes under current development with projected formal ballot dates.

• Core AADL language standard (Nov 2004) Annexes provide a way of extending the language incrementally so that tools can support or use those aspects important for their domain of application. The core textual language, meta-model and XML schema and AADL graphics are being supported now in AADL tools. Graphical tools are just becoming available. Specific tools will be discussed later in the paper. Version 2 of the standard will include new core capabilities.

-

AADL Language

The AADL provides components with precise semantics to describe computer system architecture.

Components have a type and one or more implementations. Software components include data, subprogram, thread, thread group and process. The hardware components include processor, memory, bus and device. The system component is used to describe hierarchical grouping of components, encapsulating software components, hardware components and lower level system components within their implementations.

Interfaces to components and component interactions are completely defined. The AADL supports data and event flow, synchronous call/return and shared access. In addition it supports end-to-end flow specifications that can be used to trace data or control flow through components.

The AADL supports real-time task scheduling using different scheduling protocols. Properties to support General Rate Monotonic Analysis and Earliest Deadline First are provided in the core standard.

The core also provides a property extension language to define properties needed for additional forms of analysis. Execution semantics are defined for each category of component and specified in the standard with a hybrid automata notation.

Modal and configurable systems are supported by the AADL. Modes specify runtime transitions between statically known states and configurations of components, their connections and properties.

Modes can be used for fault tolerant system reconfigurations affecting both hardware and software as well as software operational modes.

The AADL supports component evolution through inheritance, allowing more specific components to be refined from more abstract component. Large scale development is supported with packages which provide a name space and a library mechanism for components, as well as public and private sections.

Packages support independent development and integration across contractors.

AADL language extensibility is supported through a property sublanguage for specifying or modifying AADL properties. The AADL also supports extensibility through an annex extension mechanism that can be used to specify sub-languages that will be processed within an AADL specification. An example is the Error Modeling Annex which allows specification of error models to be associated with core components.

A number of other papers are referenced for a more detailed description of the language [START_REF] Feiler | The SAE AADL Standard : An Architecture Analysis & Design Language for Developing Embedded Real-Time Systems[END_REF][START_REF] Tokar | The SAE Architecture Analysis and Design Language (AADL) Standard : A Basis for Architecture-Driven Embedded Systems Engineering[END_REF][START_REF]2C Subcommittee "The SAE AADL Standard: A Language Summary[END_REF].

Model Based Development and Process Integration

Model Based Process

The Model Based Development process we have used in our laboratory in the past with MetaH includes the concepts of architectural specification, architectural analysis, and automated integration with generation of communication, glue code and the system executive to construct the final system. The AADL supports all the MBD concepts of MetaH and adds significant additional capability and flexibility in a public standard. See figure 3 for the discussion below.

Architecture analysis is rerun each time the specfication is updated, to provide model checking of the architecture as the architecture itself is refined (early trade-off analysis of architectural styles and hardware/communication effects or changes during the development or lifecycle) and as software components are developed and refined. Properties reflect the attributes of hardware and software components, connections, and ports and along with language semantics are used in analyses. Properties can capture estimates, requirements, or component options. Estimates may proceed to final values based on measurement as development proceeds. The integration of property values (estimates to measured) can be compared to higher level requirements.

Multiple architecture analysis methods, such as schedulability, latency, safety, are selected and run on the system model as it is incrementally developed. Models can be high level, low fidelity abstractions for some analyses, or early in development. The specification is refined during development or as risks are discovered. Large models may be generated from system databases.

Analysis methods provide the cross checking needed to understand the effects of system change on scheduability, latency, safety, utilization, fault tolerance etc. The analyses themselves can be incrementally added as new analysis tools become available by adding the appropriate properties throughout the system lifecycle. System of systems integrators can collect AADL specifications of lower level systems and analyze the higher level integrated system. Analysis methods and analysis tools will have to be selected consistant with the system architecture approach used. System developers will develop some special analysis for their own system implementation style and as a system engineering competitive advantage.

Software component source code is supplied by the user and can be generated from component generators (such as from Matlab/Simulink or Beacon), hand coded, or reused/re-engineered. Given the AADL specification, source code for the application and the execution environment (processors, buses. memory, devices plus operating system, compilers etc), tools can automate the process of system configuration, composition and runtime system generation. These system integration/generation tools need to be consistent with the analysis methods and AADL semanticsgenerated according to the AADL specification. However, with generation, prototypes can be rapidly developed to experiment with the system effects due to architecture changes or component changes that affect system performance.

Process Integration with UML, Simulink

The AADL UML profile will provide a means to integrate UML and AADL application development processes. The AADL profile will provide precise, component based semantics for capturing the computer hardware and software runtime architecture and to support its formal analysis. The figure below from Rockwell [START_REF] Mettenburg | AADL Opportunities at Rockwell Collins[END_REF] provides an example of the mapping between UML and the AADL and illustrates their desire to use the AADL UML Profile.

The resulting model can then be analyzed by any AADL-based tool through the XML interchange format, or by tools that interface directly to the AADL profile in UML. UML tools could also support textual AADL output as a means of bridging to other tools. The TNI Europe toolset, STOOD [START_REF] Dissaux | Stood and the AADL[END_REF], already provides a number of capabilities for integrated use of UML and AADL.

Stong interest has also been expressed for integration with Simulink from a number of AADL users. AADL components and semantics could be used as a bridge to Simulink or another component generator technology to guide component generation to the architectural specification. The AADL Programming Language annex [START_REF] Tokar | SAE Architecture Analysis & Description Language -Programming Language Guidelines[END_REF] provides guidance for building/integrating AADL compliant systems in C and Ada. Several emerging AADL tools that have already demonstrated code integration/generation capability are listed under the tools section.

Tool Strategy and Progress

Open Source to Commercial

The SEI, via Dr. Peter Feiler, the principle author of the AADL standard, developed the Open Source AADL Tool Environment (OSATE) [START_REF] Feiler | Open Source AADL Tool Environment (OSATE)[END_REF]. It was developed in the Eclipse framework using the metamodel standardized for the AADL. It provides the standardized XML definitions for use by Eclipse AADL plug-in analyses or interfacing with external toolsets. Its available at http://www.aadl.info.

The Eclipse tool framework and the AADL tools developed within it provide significant power for the development or integration of analysis tools. Analysis plug-ins are much easier to write and customize than stand-alone toolsets, they focus on the extraction of data and its analysis with methods provided within OSATE for traversing the XML models. Existing toolsets can be integrated into Eclipse or interfaces to tools developed in Eclipse. Stand-alone tools can also be generated from Eclipse plug-ins. See figure 4 below. There were multiple reasons for an open source toolset strategy. One was to accelerate availability of commercial tools by providing an open source tool that fully incorporates the language and provides semantic as well as syntactic checking. OSATE also has the benefit of making the full language available from the begining, and validating the language standard itself through implementing the language. It also furnishes a low entry cost vehicle for getting started with the language and provides a vehicle for in-house prototyping for the development of analysis approaches or annex extensions. It has accelerated use by early adopters of the language, prior to commercial tools. It decreases the likelihood of incompatible toolsets implementing their own flavor of the standard.

Since the AADL provides several standard extension mechanisms, industry domains, companies, and vendors can provide extensions through these forms without corrupting the standard. These extensions then can be submitted to the AADL standardization committee for consideration as part of the standard. An example of this is the Airbus developed Behavior Annex [START_REF] Filali | Cotre Annex HRT-HOOD embedding[END_REF] which is now being reviewed by the committee.

Commercial tools are highly valued by industry for their development process support and on call maintenance. The UML profile as well is being developed to make it easy for UML tool vendors to support the AADL.

Commercial analysis tools may be integrated into commercial or open source AADL tools and AADL analysis tools themselves present an opportunity for commercialization. Current commercial design tools can also be modifed and extended to support the AADL. For instance, TNI Europe is extending their STOOD Hood/UML development environment to import, capture via AADL graphics, process and export AADL.

The AADL meta-model annex [START_REF] Feiler | AADL Meta Model & XML/XMI[END_REF] includes the AADL Declarative Model and the AADL Instance model (see figure 4). The XML expression of the declarative model can be converted back into a textual specification or graphical specification of a system. The Instance model is used to simplify analysis by providing the system instance as it will be bound to the processors. The meta-model provides a specification of the language that can be used in meta-modeling frameworks to rapidly build AADL compliant toolsets, such as in TOPCASED or GME [START_REF] Eby | Experimental Platform for Systems-Security Codesign[END_REF].

Another important aspect of the standardized metamodel and XML schema is that it provides a database for analysis tool interaction that is standard. Tools can not only read from the XML models but also post back into it. For instance, a scheduling and binding toolset would be used to optimize processor and bus utilization given the constraints on binding captured in the AADL and the properties of threads and communication overheads. Given that binding, follow-on reliability, latency or safety analysis could be performed. Finally, from the system instance, the system could be automatically integrated with generation of glue code.

Additional Open Source Tools

There are a number of AADL open source toolsets either just becoming available or in the process of development. Here's a list.

• TOPCASED [START_REF] Gaufillet | TOPCASED -Toolkit In Open source for Critical Applications & SystEms Development[END_REF] -Airbus led, 22 partners participating, developing a metamodeling framework, includes AADL toolset and Graphics, AADL XML, model transformation

• OCARINA [START_REF] Vergnaud | The Ocarina Tool Suite[END_REF] -ENST AADL toolset with graphics, middleware generation and integration to AADL specification of application on network distributed processors. Creates formal model of executive in AADL and Petri nets.

• MONTANA [START_REF] Sokolsky | The Montana Toolset : OSATE Plugins for Analysis and Code Generation[END_REF] -AADL to ACRS [START_REF] Clarke | VERSA : A Tool for the Specification and Analysis of Resource-Bound Real-Time Systems[END_REF] (process algebra), formal analysis of concurrent resource utilization, scheduling -AADL to Charon [START_REF] Alur | Generating Embedded Software from Hierarchical Hybrid Models[END_REF], generation of control components and integration of hybrid control systems to AADL specification using Charon annex.

• GME [START_REF] Eby | Experimental Platform for Systems-Security Codesign[END_REF] -Vanderbilt Univ, DARPA sponsored meta-modeling framework, AADL architecture specification and system security analysis being added.

• CHEDDAR [START_REF] Singhoff | Scheduling and Memory requirement analysis with AADL[END_REF] -ENST, advanced scheduling analysis toolset

Error Modelling Annex Concepts

In fault tolerant, safety critical systems error modeling is an important aspect of architectural design and should be integrated into the architecture specification so it can be cross checked against changes. The MetaH language originally supported reliability modeling and this has been sigificantly extended in the AADL to support multiple forms of safety and dependability analysis through error models that are attached to architectural components [START_REF] Vestal | An Overview of the Architecture Analysis & Design Language (AADL) Error Model Annex[END_REF]. Some of the supported analysis approaches include hazard analysis, failure modes and effects analysis (FMEA), fault trees, and Markov processes. Honeywell has demonstrated error modeling (hazard and FMEA) using annex capabilities on a large aircraft system [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]. ASSERT has modelled a dual redundant fault tolerant computer system using the annex [START_REF] Rugina | Dependability modelling of a fault tolerant duplex system using AADL and GSPNs[END_REF][START_REF] Rugina | Dependability Modelling using AADL and the AADL Error Model Annex[END_REF].

Conclusion

The AADL provides or supports through tools significant model based embedded system engineering benefits. These include:

-Precise semantics supporting analyzable models to predict system performance and drive development -Prediction of system runtime characteristics at different fidelity -Bridge between application engineer, architect and software engineer -Prediction early and throughout lifecycle -Reduced integration and maintenance effort

The AADL also provides additional benefit based on its standardized features including: -Common modelling notation across organizations -Single architecture model augmented with properties -Interchange & integration of architecture models -Tool interoperability & integrated engineering environments

The AADL is based on over 12 years of research, over 40 experiments, other DARPA ADL's and an expert committee.

The AADL has been demonstrated on large complex embedded safety critical systems by leaders in the Avionics domain. A growing number of tools as well as transition support for AADL are becoming available, including now AADL graphics. It is time to investigate the benefits of using the AADL on your systems in the aviation, space, and automotive domains.

Acknowledgement

The author would like to thank the AADL standardization committee for their diligent efforts and willingness to share through their presentations what they are doing with the AADL. Many of the papers referenced below have been developed by committee members.

TNI

  In flu en ceA li g n m e n t E n h a n c e m e n t

Figure 1 :

 1 Figure 1 : Building from a foundation 2.2 Committee

Figure 2 :

 2 Figure 2 : AADL Committee

  Textual language, semantics • Graphical AADL Notation Annex (April 2005) -Enables graphical AADL programming • AADL Meta-model/XML Annex (April 2005) -Model interchange & tool interoperability • Programming Language Annex (April 2005) -Mapping to Ada, C/C++ • Error Modeling Annex (Oct 2005) -Reliability and fault modeling • UML Profile for AADL (Mar 2006) -Transition path for UML practitioner community • Behavior Annex (July 2006) -Detailed component behavior modeling

Figure 3 :

 3 Figure 3 : Model Based System Engineering

©

  Copyright 2005 Rockwell Collins Inc. All Rights Reserved AADL Opportunities at Rockwell Collins 25 cd Use Case M odel «AADL_Process» Applic a tion -T hread1: AADL Com ponent Im plem entation = Work -T hread2: AADL Com ponent Im plem entation = is not necessarily a compliant example) AADL

Figure 4 :

 4 Figure 4 : Standardized and Simplified Tool Integration Supported

Based Tool Integration Strategy Textual AADL Scheduling Analysis Reliability Analysis Safety Analysis AADL Runtime Generator Graphical AADL Semantic Checking AADL Front-end Research prototype Commercial Tool Project-Specific In-House Project-Specific In-House Declarative AADL Model AADL Instance Model Graphical Layout Model

	www.aadl.info www.aadl.info

13

XML-

Applications & SystEms Development

AADL in Use

Some of the early adopter presentations on the AADL are highlighted in the slide in Figure 6. These presentations and many others are available on the AADL website www.aadl.info.

They include experimentation using the AADL to capture a reference architecture for military aircraft (EADS [START_REF] Windisch | ASAAC Modelling with AADL[END_REF]), the development of a system engineering process using the AADL for validation of correctness and integration of the dynamic and structural aspects of the aircraft computer system (Airbus [START_REF] Farail | COTRE a Software Design Workshop[END_REF]), a presentation on an integrated UML and AADL process for the development of weapon system Plug & Play (PnP) architectures (General Dynamics [START_REF] Lacerte | AADL and MDA -Early Experience Applied to Aircraft-Weapon Integration[END_REF]). Also included is a presentation on the modelling of a large modern aircraft system with architectural tradeoff analysis, scheduling and safety analysis (Honeywell [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]) and a modelling and analysis of a modern helicopter architecture for system workload, partitioning and tuning of the switched network (Rockwell [START_REF] Statezni | Analyzable and Reconfigurable AADL Specifications for IMA System Integration[END_REF]). Also pictured is a presentation on the development of a system engineering approach using the AADL and a formal methods oriented development process (ESA, ASSERT [START_REF] Conquet | ASSERT -Automated proofbased System and Software Engineering for Real-Time systems[END_REF]). These presentations demonstrate a variety of uses, integration into system engineering processes and application to significant modern, complex, large, performance critical systems for the AADL.

Figure 7 provides a list of Aircraft that Honeywell has modelled using MetaH/AADL [START_REF] Vestal | Methods and Tools for Embedded Distributed System Scheduling and Schedulability Analysis[END_REF]. This presentation also provides Honeywell's tool development strategy for AADL tools.

Air transport aircraft IMA (simplified production workload)

Globally time-triggered 6 processors, 1 multi-drop bus 105 threads, 51 message sources

Military helicopter MMS (first release, partial)

Globally time-triggered 14 dual processors, 14 bus bridges, 2 multi-drop buses 306 threads, 979 [source, destination] connections

Air transport aircraft IMA (preliminary, partial)

Globally asynchronous processors, precedence-constrained switched network 26 processors, 12 switches 1402 threads, 2644 [source, destination] connections

Regional aircraft IMA (production workload)

Globally time-triggered 49 processors, 2 multi-drop busses 244 processes (TBD threads), 3179 [source, destination] connections [START_REF] Feiler | Muti-Fidelity Architecture Modeling[END_REF][START_REF] Feiler | Pattern-Based Analysis of an Embedded Real-Time System Architecture[END_REF][START_REF] Feiler | Embedded Systems Architecture Analysis Using SAE AADL[END_REF][START_REF] Peter | Improving Predictability in Embedded Real-time Systems[END_REF]. They have also developed (and are near publication) a Practitioner's Guide [START_REF] Hudak | Developing AADL Models for Control Systems: A Practitioner's Guide[END_REF] on AADL and Control Systems Applications and a User's Guide [START_REF] Gluch | User's Guide on the AADL Notation[END_REF] to AADL notation.


J-P Blanquart
email: jean-paul.blanquart@astrium.eads.net

A Rossignol

D Thomas

Toward model-based engineering for space embedded systems and software

Keywords: systems engineering, software engineering, modelling, automatic code generation

Toward model-based engineering for space embedded

systems and software

Introduction

Future space system projects are characterised by stringent needs in safety, autonomy and in the capability to include more and more functionalities. In these computer-based systems, the embedded software, which constituted only a small part of the global system a few years ago, has become a key element to meet all the needs. Facing to the ensuing complexity, quality and safety requirements are getting difficult to manage and usually lead to cost overrun and delays in development. Indeed, the new place of software at system level was not anticipated soon enough. System engineering aims at supporting the transformation of operational needs into a solution achieving a tradeoff between requirements, technological possibilities (including reusable components) and cost and delay constraints. However it is still a strongly empirical activity:

• it consists of paper documents that cannot be checked with confidence, • it does not guarantee a full traceability, for instance, it is hard to know if the design fulfils all the requirements with consistency, • it includes an expensive phase of handmade coding, integration and tests, supporting only little reuse. It is therefore not entirely surprising that operation failure reports reveal more and more design errors. In the intention of detecting this type of errors early in the development cycle, new means (e.g. languages, methods and tools) are considered, evaluated and carried out in several practical studies in co-operation with operational units. The purpose of this paper is to make an overview of model-based contribution in support to embedded system engineering, based on various studies and experiences that are carried out in space domain: This paper is organised as follows: Section 2 is first devoted to a general overview of selected principles, standards and tools. Then we split results and achievements upon two themes:

• Section 3 about control engineering and code generation from continuous models, from needs capture to automatic code generation on an AOCS functions subset using Matlab/Simulink® models; • Section 4 about computer-based system engineering (hardware and software): requirements analysis and design and validation for FDIR, and provable system and software engineering. Some perspectives and conclusion are finally discussed in section 5.

Principles, standards and tools

2.1 Embedded system design An embedded system typically consists in a collection of hardware and software elements controlling a process. For instance, the avionics system of a satellite is in charge of flight, navigation and radio communications. It requires fine control application with real-time software bound to a specific execution platform. These three domains of knowledge (control, software, hardware) are characterized by severe constraints with efficiency and dependability requirements to be verified.

Control design: Control applications usually transform physical parameters. Formal models are based on continuous (transfer) functions using differential equations to model behaviours. In space systems, the overall survival and performances depend on control applications (e.g. AOCS) but validation tests are limited because space environmental conditions are difficult to recreate. Then, many efforts are made on studies and simulations that can be performed on tools such Matlab/Simulink® ( [START_REF]Matlab/Simulink[END_REF]) or Scilab/Scicos®. Software design: In the last decades, formal methods and languages were proposed to specify, document and whenever possible validate (realtime) software. At specification phase, B or Z approaches ( [START_REF]ISO: Information technology "Z formal specification notation" syntax, type system and semantics[END_REF], [START_REF] Spivey | The Z Notation: A Reference Manual[END_REF]), for instance, apply mathematical concepts (logic and assertions) to model and verify the system. A more practical way for specification is based on scenarios using Message Sequence Charts (MSC) included in SDL [4] and UML standards. Then behavioural description languages for reactive are mainly divided in two approaches. PROMELA), process algebras (e.g. CSP, LOTOS), Petri Nets and their specific timed extensions can be used for asynchronous systems. The precision of formal methods can be exploited by tools for simulation, tests or verification in support to validation. However, in the industry, formal languages were dismissed in favour of semi-formal languages (mainly model-based) which are easier to integrate in current processes. As an example, UML is intensively used for software development. On the other hand, there are no specific UML language elements for expressing explicit parallelism and we observe a strong lack of semantics that can imply incoherency between diagrams. AADL ( [START_REF]Architecture Analysis & Design Language Standards Document[END_REF]) is then seriously considered by the embedded systems community. It can represent tasks, time of execution, deadlines, scheduling, and useful information for specific real-time analysis. Indeed, in addition to real-time constraints, embedded systems are characterized by further non functional requirements such as memory occupation, electric consumption and tight relation with hardware (e.g. specific executive platform). Embedded hardware design: Programmable hardware (e.g. ASIC, FPGA) are more and more used to integrate functions on hardware (e.g. smart sensors or actuators). Languages for describing hardware, such as VHDL and Prolog, are called hardware description languages. They integrate specific means to describe concurrency and wired communications based on architecture which make them far from common software languages. System design: The coupling of subsystems from different modelling domains implies the necessity to manage complexity at system level. In complex embedded systems, both hardware and software must be taken into account and tests and verification have to be done before implementation and integration. Then, new formalisms are required to support this multi-domain approach. For example, SystemC ( [START_REF]SystemC Community[END_REF]) enables design, simulation and verification of functions, and their implementation on hardware or software without re-engineering. In the same way, AADL and UML2.0 seem to have the ability to manage more than only software components as for Matlab/Simulink/Stateflow® which bridges discrete and continuous domains. Requirements analysis, modelling and traceability between several domains are also objectives of this kind of new languages. Our last consideration is for the incoming SysML ( [START_REF]SysML Forum Society[END_REF]) that should enable the specification, analysis, design, verification and validation of a broad range of systems including hardware, software or mechanical parts.

Selected technologies for space embedded systems engineering

Model-based: Satellites are complex remote systems that must be safe from the first (and only) flight. These systems can be hardly tested in real conditions (space environment) before operational launch. In this way, the needs essentially concerns fine simulation (verification), formal proof (validation) and complexity management from requirements analysis down to final integration. The principle we are following in order to fulfil these requirements is Model Driven Engineering. Models are used to build a virtual representation (logical solution) of the system to enable early prediction of behaviour and performance before teams proceed to implement designs. The Model Driven Architecture (MDA) standard [START_REF]Model Driven Architecture Guide[END_REF] is originally an approach to use models in software development. It aims to implement a system by transformations from a Platform Independent Model (PIM) that concerns only domain aspects (logical solution) and enables a greater understanding of the user and system requirements. A transformation uses a Platform Dependent Model (PDM) that consists of chosen technical components (Physical solution) to implement the system. This transformation also requires a mapping that associates elements from PIM to elements from PDM. The result is called the Platform Specific Model (PSM). Separation of domain and technical aspects may improve overall clarity, portability, interoperability and reusability. Moreover, using different viewpoints, corresponding to different levels of abstraction for PDM, encourages iterative construction and iterative verification. Our studies aim to adapt processes and languages to embedded system engineering so as to benefit from this kind of approach. MATLAB®, UML2, AADL and SystemC languages were first selected to support a new system process. SysML will surely act as a new candidate for high level analysis.

-Matlab/Simulink®: Despite other alternatives are proposed, Mathworks tools are likely becoming de facto standards for control application development. However, there are still problems to implement control algorithms because transition from continuous to discrete can alter the function. SCAOGEN study relates to automatic generation of code from MATLAB models (cf. section 3). -UML2, AADL: As for Matlab, UML2 is a widely known standard with powerful associated tools. Several studies on critical real-time embedded systems also promote the use of AADL which has become an international standard since November 2004. Indeed, with embedded systems we must consider behaviour at execution, that is to say how software is implemented on execution platform and AADL allows these implementation choices to be described. Semi-formal and graphical methods were preferred because formal methods seem too specialised and cannot satisfy system level requirements. Selected languages give intuitive notation which makes communication between analysts and customers easier. Moreover, UML lack of semantics and real-time elements can now be avoided by the introduction of profiles (e.g. OMG/SPT [START_REF]UML Profile for Schedulability, Performance, and Time Specification[END_REF]) and design patterns. Indeed, UML2 authorises customization with stereotypes and tagged-values to easily adapt specific domain aspects. For example, additional information from formal models can be associated to system model by annotations (tagged values). These elements should be used to generate (by transformation) implementation code or simulation and analysis models for specific tools. AADL presents the same concepts using annexes and user properties. ASSERT project and FDIR study (cf. section 4) are practical overviews of information processing systems engineering using AADL and UML2. Commercial I-Logix Rhapsody tool for UML and OpenSource OSATE Eclipse plug-in for AADL are used in our current studies.

-SystemC: HW/SW interfaces must be considered for errors avoidance. SystemC is based on ANSI-C and uses additional libraries to manage software /hardware programming and co-simulation. The HW/SW CODESIGN study aims to introduce a new system/software/hardware co-design process. Tools from Mathworks®, Magilem®, Celoxica® and Nepsis® are first considered.

From needs capture to automatic code generation on an AOCS functions subset using Matlab/Simulink® models

Up to now for each new satellite, Attitude and Orbit Control System (AOCS) software is mainly developed from scratch with few reuse at functional and software levels. Technologies and domain analysis are now ready to improve this situation by allowing efficient design and components reuse of AOCS software.

After defining and implementing an efficient coengineering and co-validation process between AOCS studies team and AOCS software team, EADS Astrium intends to go further. We will present how EADS Astrium prepares implementation of such an enhanced development process based on the following approach and technologies:

• A common reference process both for AOCS and software engineering teams able to support needs capture, requirements definition, design analysis, code generation, functional simulation, functional and software verification.

Process

From prototype model to ACG model: ACG has a great impact on the AOCS studies development process.

Right now modelling in the Matlab/Simulink® environment was considered has a prototyping activity performed during the preliminary A/B phases. So, no specific rule or standard was written. The main effort was brought on the C phase simulator which is a high fidelity simulator including the actual AOCS software. The AOCS software was written from AOCS specification, itself partially written from preliminary Matlab/Simulink® models. Once the HIFI simulator is available, the Matlab/Simulink® models are no more really maintained. With ACG, the reference becomes the models themselves. So many constraints appear. The models must permit not only the auto-coding but they have to be readable and maintainable. These constraints make the modelling activity heavier, which is no more compatible of fast prototyping approach used during preliminary A/B phases. This leads to conclude that two kinds of modelling can be managed at AOCS studies level: • Fast prototyping modelling approach similar to the current usage of modelling, maybe lightly improved by introducing general rules favouring the readability.

• ACG modelling approach that has to account strict rules allowing determinism of execution and code generation. The prototyping model is not supposed to be maintained and used to initialise the final model. The proposed new process is illustrated in the following Figure 1 and its main steps described further below the figure. AOCS model co-engineering: once the AOCS concepts are considered validated and documented, the co-engineering phase between the AOCS and the software teams starts to refine the model and add all the functionalities which were not mandatory to validated the AOCS concept. During this phase, the software team checks the whole models against the modelling rules and especially the auto-codeability. Both teams work together on the same model.

SW development: this point concerns the part of AOCS software that could not be auto-coded. The process would then be similar to the current one. The both team agree first together the software specification then the code is developed and unit tested before generating "S-function" to be inserted in the Simulink® model.

AOCS model functional validation: this phase is realised by AOCS studies teams with support of software team if debug is required. This phase is not much impacted with respect to the current process.

In this phase all tests are performed on models but not yet on the generated code in order to ease the tuning and the debug of the model.

Code generation: once the model is completely validated the code generation can be performed. An "S-function" of AOCS software is generated to be inserted in the Simulink® environment. A subset of test is run to check that code generation has not introduced error.

AOCS functional validation and performances: this step remains similar to what it is in the current process. The whole performance tests campaign is run on the AOCS flight software.

Architecture

The analyses performed commonly by AOCS studies and software teams shown that it was possible to define together an AOCS reference architecture that favours, on one hand, the reuse of AOCS functions by defining building blocks and on the other hand, the code generation because it accounts elements of software architecture standard. This AOCS reference architecture imposes new constraints for AOCS teams but also provides advantages that were already experimented at software point of view. Once the architecture is understood, it's easier to move inside the model, because all modes, all projects follow the same standards. This makes the models more readable and eases the maintainability of the models. It also eases the reuse of building blocks, because building blocks are thought to be inserted in this kind of architecture. So when a new project respects the reference architecture, it is then possible to reuse existing building blocks.

Modelling rules and code generation issues

Coders' performances: code generation on Simulink® models gives quite good results if accounting few constraints in the definition of the models.

• Ratio of Matlab® algorithm with respect to the rest of AOCS; Modelling standards and rules: quality of generated code depends directly on the quality of the models. So standards or rules previously applicable to software development become new standards or rules applicable to models development. They are of two kinds: standards and rules for models writing to ease the code generation configuration and ensure generated code readability; and standards and rules for models architecture which ensure models (and software) readability and maintainability. In order to benefit of the software experience in terms of software architecture that accounts not only AOCS needs but also operability and maintainability needs, it is foreseen to apply to models development the same approach that the one currently applied on software development. That is, an AOCS reference models is defined that accounts all constraints either AOCS, or FDIR or operability. Then, this reference models defines the framework for any AOCS models development. It defines the backbone of the model and the software architecture. It defines:

• Standard model breakdown • Code generation configuration • Standard interfaces • Standard dynamic behaviour
• Standard activities scheduling profile Models sharing: with the ACG approach the models become the reference from which the code is generated. That means that the models have to be complete, in terms of which functionalities will have to be in the final software. They also have to include all information necessary for code generation. This means that the models have to be shared by the AOCS studies team and the software team. The first one creates the models from the AOCS models framework. The second one completes them with code generation information, eventually updates them to permit auto-code-ability and add missing functionalities. The AOCS and the software teams shall then be able to share the same model to make it evolve.

Tools evaluation

Among tools available for code generation from Matlab/Simulink® models (Mathworks®, d-SPACE® and Esterel SCADE®), two tools were selected for evaluation:

• The Real Time Workshop Embedded Coder (RTW-EC®) from the Mathworks® • The TargetLink® 2.0 from d-SPACE® RTW/EC® seems yet less mature and intuitive than TargetLink®, but it accepts all Simulink® blocks and already integrates interesting features (like bus and embedded Matlab® function) that, even not yet completely operational, are very promising for targeted kind of model. It seems therefore providing a better capability of improvement in the short-term and will be used at least for the study. This choice will have to be confirmed at the end of the study.

Model-based engineering for embedded systems

The development of embedded systems, in particular for critical applications, calls for methods to master their complexity and the many interactions between their components and interrelations between hardware and software. EADS Astrium has engaged a set of studies, pilot projects and experiments investigating the potential benefits of model-based approaches for the development and validation of embedded systems. Among them, two studies are highlighted in this section, addressing on the one hand model-based approaches for the development of embedded fault and error management functions, and on the other hand model-based approaches as a support to the provable development of embedded hardwaresoftware systems.

Embedded fault management functions (FDIR)

The dependability of space systems is ensured (in addition to a set of fault prevention and robust design approaches) by specific on-board functions dedicated to the detection and diagnosis of faults and the selection of appropriate recovery or reconfiguration actions. These functions constitute globally what is called FDIR in space systems (for Fault Detection, Identification and Recovery).

The FDIR function must be able to maintain (or restore) the best achievable level of mission in case of adverse events such as faults or failures of onboard components. For advanced autonomous and complex space systems, the FDIR function must react to a very large number of potential events and combinations of events, taking into account the fact that not all events may be fully covered and that an appropriate balance must be found between the need to maintain or restore the mission (availability) and the need to maintain the ultimate survival capabilities of the spacecraft (safety). Space systems FDIR is therefore designed as a complex architecture, generally highly hierarchical, of detection and reaction mechanisms whose many explicit or implicit (based e.g., on different reaction time) interactions make FDIR development and validation particularly difficult.

In a recent study [START_REF] Jp | Rapport d'étude: Architecture FDIR pour satellite autonome[END_REF] we investigated model-based approaches for the development and validation of FDIR for advanced autonomous space systems. For this study, AADL appeared as particularly interesting, thanks to its capability to model the actions of the FDIR function on the very configuration of the physical architecture (through the definition of modes, each associated to a particular configuration of physical components and a particular mapping of functions and software components).

We also aimed at defining a modular progressive approach for the construction of complex FDIR functions, both to support complexity mastering and to provide enough flexibility to further adapt or update the FDIR functions during late development or even in-orbit maintenance. We therefore elaborated a library of elementary "FDIR components" that can be progressively composed into a complex FDIR function. This approach also exploits the capability of AADL to model both functional elements and components of the physical architecture and model their relationships and mapping. Similarly, we defined elementary components both for FDIR strategy (e.g., timeout, re-try, switch nominal and backup) and for FDIR architecture (e.g., hot duplex, cold duplex, majority voting).

As illustrated in Figure 2, this approach allows a progressive construction and validation of a complete FDIR to be performed by composition of architectural elementary components on the one hand, and of procedural elementary components on the other hand (defining the global strategy to exploit the various reconfiguration possibilities provided by the available architecture).

Action1 Action2

Action3 Action4 However we also aimed at providing a powerful support to the validation of complex FDIR functions, including for instance the verification of the correctness of the various possible sequences of events and reconfiguration actions or the estimation of the reconfiguration duration.

Though there may not be "built-in" obstacles to perform such analyses on an AADL model, the current status of its definition and of its support tools does not provide the support we needed in particular terms of detailed behavioural description and analysis.

We then complemented the AADL models with UML models of the detailed behaviour, especially the transient behaviour, on event occurrence (fault), from one configuration to another. As illustrated in Figure 3, the models can be used to support various analyses or simulation (on automatically generated code). Considering the complexity, criticality and also cost of embedded systems, there is a strong need of development and validation approaches capable to provide the desired level of confidence in a reasonable amount of cost and time. EADS Astrium has engaged studies towards this aim and in particular through its participation to the ASSERT project 1 . The ASSERT project aims at improving the system and software development processes for critical embedded real-time systems in the aerospace domain by: • Identifying and developing proven critical system families' architecture, using a proof-based development process supported by formal notations, component models, processes and tools; • Developing associated building blocks that can be composed, tailored and verified in open frameworks. Among other activities, modelling tasks cover the elaboration of models of system families and models of their components to be instantiated and composed as building blocks of a given target system. Three modelling levels are considered: functional, software and physical architecture. This is illustrated in Figure 4 on a space system with a subset of applications (GNC, Guidance and Navigation Control, TMTC, Telemetry and Telecommand and Thermal control) mapped on an architecture provided for illustration, characterised by the existence of specific processors dedicated to highly critical functions (which could be achieved with appropriately managed criticality levels within a processor, as also investigated in the study). In the final process elaborated by the ASSERT project, the model of a given system will be defined as an adaptation of the system family model, by composition of properly instantiated or tailored building blocks, with provable composability properties. These properties, and their proofs, address mainly real-time properties and assumptions (synchrony or asynchrony characteristics, deadlines, worst-case execution time etc.) and dependability properties (fault assumptions, failure modes, properties such as atomicity etc.).

Consequently the ASSERT modelling framework, based on AADL and UML, will include a set of extensions proposed to AADL, to cover the formal expression of all the properties defined in the ASSERT process, to enable their verification by support tools, and to support the generation of system glue code with predicted performance attributes. This extended AADL will be implemented through an UML profile ensuring continuity of the modelling, proofs and code generation chain, from system level down to software level.

Conclusion

After very good results on using Matlab/Simulink® models and automatic code generation for rapid prototyping, the same technology is now explored for operational software provided that:

• It implements a well defined process;

• Modelling is compliant to a reference architecture and some design rules; • The Code Generator is customisable and produces source code that is efficient, easy to integrate and with the right level of quality. Concerning system and software modelling, methods and languages such as AADL and UML, present some important and interesting characteristics. Among them, we can mention the AADL capability to formally define the links between the software (or functional) elements and their execution support, and the capability to identify how a function is implemented and executed. It then supports the system development and validation, at least theoretically, in particular through detection (or prevention) of mapping errors and through analyses (e.g., data or control flow, real-time properties or partitioning properties). In addition, AADL provides a natural support to the modelling of functions which act on the configuration of the physical architecture, which is particularly well suited for FDIR functions modelling. However AADL is still limited, at least in its current definition, in terms of detailed behavioural description, and moreover is still missing powerful support tools. UML provides useful features in terms of e.g., highlevel modelling, and behavioural modelling and verification. However the semantics does not fully support the consistency between the different diagrams (though this may be solved through additional profiles). AADL and UML finally provide complementary solutions for the development and validation of complex embedded systems and software, which strongly calls for the definition and implementation of gateways between them. These preliminary results show that all these new methods and languages support at least partially the system and software engineering needs and that, to a large extent they are very promising in terms of definition, verification and validation. However the selection and utilisation of these different formalisms, and languages still necessitate: • To complete for each of them a detailed assessment; • To integrate them into a well defined process;

• To be supported by a rigorous method usable within an operational industrial domain.

Glossary

ACG

Figure 1 :

 1 Figure 1: AOCS and software new process Initial AOCS model building: the ACG model is first developed by the AOCS team form the AOCS reference model template and the preliminary prototype model. At this stage, the reference architecture shall be respected and as far as possible all modelling rules. During this phase of AOCS design, the software team can support the AOCS team to instantiate the AOCS reference model and especially on parts that are nut usually integrated in the AOCS models like the modes management and the FDIR aspects. This first model is tested in closed loop in the Simulink® environment by the AOCS studies team.

Figure 2 :

 2 Figure 2: Progressive model-based FDIR construction approach

Figure 3 :

 3 Figure 3: Model-based behavioural analysis and simulation

1 ASSERT:

 1 Automated proof based System and Software Engineering for Real-Time applications, Integrated Project (n°4033) of the 6 th Framework Programme, Information Society Technology, European Commission. The ASSERT project has started in September 2004 for 3 years, with 29 academic and industrial partners under the coordination of the European Space Agency, ESA.

Figure 4 :

 4 Figure 4: Three levels of modelling (example of architecture)

  Automatic Code Generation AOCS Attitude and Orbit Control System ASIC Application Specific Integrated Circuit CNES Centre National d'Etudes Spatiales FDIR Fault Detection, Identification and Recovery FPGA Field Programmable Gates Arrays HIFI Simulator: High-Fidelity simulator with flight software in-the-loop SoC System on Chip

Acknowledgement

The authors acknowledge the contribution of their colleagues to this work and in particular Pierre Yves Farges and Michel Horblin (EADS Astrium).

The authors wish also to thank CNES and the European Commission, which funded all or part of the studies supporting the results and discussions presented in this paper.

Code generation from StateFlow® models is less efficient than for Simulink but remains acceptable. Code generation from Matlab® models is still problematic: generated code is not easy to read and is quite inefficient especially in matrices handling. The analysis shall continue to define if it is possible according to the following criteria:


Alexandre Chagnes
email: alexandre.chagnes@univ-lorraine.fr

RECENT ADVANCES IN HYDROMETALLURGY FOR THE DEVELOPMENT OF A SUSTAINABLE PRODUCTION OF LITHIUM-ION BATTERIES By

Keywords: copper recovery, ammonia leach, solvent extraction, electrowinning, process development, pilot plant

come

INTRODUCTION

In 2013, the global sales of Li batteries reached nearly 12 billion US$ and this market is anticipated to reach about 24 billion US$ by 2020, driven by the growing use of Li-ion batteries in hybrid electrical vehicles (HEV) and fully electrical vehicles (EV) as well in many other applications. Lithium is used in many applications including glass and ceramics, lithium batteries, lithium greases, air treatment, steel and aluminium industry and pharmaceutical industry and polymers [START_REF] Pillot | Battery Market Development for Consumer Electronics, Automotive, and Industrial: Materials Requirements and Trends -Presentation given at the Advanced Automotive Battery Conference 2014 -AVICENNE Energy[END_REF] [START_REF]Lithium Process Chemistry:Resources, Extractions, Batteries and Recycling[END_REF] . Figure 1 shows an overview of the linkages between the natural lithium sources (brines and minerals), the main derived primary products (lithium carbonate, hydroxide, chloride, metallic lithium), the secondary derived, products and their respective main uses and applications. The main market for lithium in the next decades is lithium-ion batteries due to the emergence of electric vehicles and the development of energetic transition. In particular, many researches focus on the search for high energy density batteries for electric mobility. However, this race of high-energy density storage technologies must not be achieved at the detriment of safety and sustainability of lithium-ion batteries. Reducing the environmental footprint of lithium-ion batteries remains a priority. Sustainability of batteries can only be achieved providing that each stage of the value chain is optimized in terms of efficiency, energy and resources consumption, gas and effluent emission, material production process, etc. Further, the vision of the circular economy encourages the closing of loops by means of recycling, which challenges today's value chains and its various actors [START_REF] Chagnes | A brief review on hydrometallurgical technologies for recycling spent lithium-ion batteries[END_REF] . For these changes in the value chain to take place, not only technological achievements are necessary but innovations in the supply chain system and in business models for both energy storage devices and its applications are most likely required. [START_REF]Lithium Process Chemistry:Resources, Extractions, Batteries and Recycling[END_REF] .

Figure 1. Supply chains linking lithium deposits to lithium applications and uses

The huge market of electric vehicle will be responsible for an important rise of cobalt, nickel, manganese and lithium demand since current batteries use these raw materials. For this reason, the future demand of cobalt, nickel and lithium will likely increase by 31%, 69% and 46% between 2017 and 2030, respectively [START_REF] Pillot | R&D Stream Lithium-Ion Development & Commercialization Delivering Higher Performance at Lower Cost[END_REF] . While 130 million electric vehicles could circulate around the world by 2030, Europe estimates the need for cobalt for the automotive sector between 1.6 and 2.1 million tonnes by 2030, an annual demand that would rise from 6650 tons in 2017 to 300,000-400,000 tons. In Europe and according to the scenarios, demand is estimated between 40,000 and 120,000 tons per year by 2030. Therefore, tightness in metal market will be strong in the next decade and supply risks have to be anticipated, especially in European countries where there is no or few cobalt, nickel, manganese and lithium deposits. In Europe, 239 deposits containing cobalt have been identified. Some countries like Finland and Sweden are already mining the ore. Today, the annual production of cobalt in the European Union is about 2,300 tons per year, and it will be insufficient to cover a demand nine times higher. Combined with the establishment of an efficient recycling sector, the accelerated exploitation of cobalt deposits in Europe could cover about 15% of the demand of the old

Lithium minerals Brines

Mineral concentrates Lithium carbonate Li2CO3

USES AND APPLICATIONS OF LITHIUM PRODUCTS PRIMARY PRODUCTS

Lithium hydroxide LiOH

Lithium chloride LiCl

Other lithium salts acetate, benzoate, phosphate ...

SECONDARY (DERIVED) PRODUCTS

Other lithium salts nitrates, silicates, sulphates ...

Lithium bromide LiBr

Lithium zeolites Metallic lithium Li

Other lithium salts stearate

Technical-grade products for:

• Glass and ceramics

Numerous aplications (examples):

• Li-ion batteries (LiClO4)

• Aluminium production (LiF)

• Nuclear physics (LiF)

• UV optics (LiF)

• Organic Light-Emitting Diodes (OLED) (LiF)

• Long-life batteries in pacemakers (LiI)

• High-temperature batteries (LiI)

Butyllithiym

Production of elastomers

Other organic Li compounds

• Al-Li alloy (aircraft manufacturing)

• Primary batteries

Catalysis Air separation

Primary products directly derived from brine or minerals

Raw materials for pharmaceuticals and polymers production

Main Li uses and applications

LITHIUM DEPOSITS

Other important raw materials LEGEND continent by 2030. Europe will, however, remain heavily dependent on imports. In this context, it appears strategic to consolidate trade agreements with countries such as Australia or Canada. The same scenario is expected for lithium since European lithium importation reaches 86% to face up its needs. However, a large lithium reserve exists in Europe, and more particular in Portugal where two large mines could start operating in 2020. For this goal, it appears of great importance to develop breakthrough processes in order to reduce operation costs since the production of lithium extracted from Portuguese granite rock is about 2.5 times more expensive than that produced from Chilean brine deposits.

More generally, there is a need to develop efficient, selective and sustainable hydrometallurgical processes for the recovery of these metals from primary and secondary resources. This paper highlights a few recent advances, which contribute to improve the current processes by optimizing them or that pave the way for breakthrough processes.

COBALT, NICKEL AND MANGANESE SEPARATION

Nickel is mainly extracted from laterite and sulphide ores while cobalt is mainly extracted from linneaite and cobaltine, and manganese is found in the rocks of pyrolusite, haussmannite and braunite [START_REF] Lateef Ibrahim | Hydrometallurgical Processing of Manganese Ores: A Review[END_REF] . Pyrometallurgy is still the preferred technology to recover these metals in addition to their recovery as a by-product from copper ores. Nevertheless, laterite ores containing both nickel, cobalt and other metals of economic interest are increasingly being treated by hydrometallurgical methods or methods combining both pyrometallurgy and hydrometallurgy [START_REF] Chagnes | Fundamentals in electrochemistry and hydrometallurgy[END_REF] . However, the trend is changing in favor of hydrometallurgy because of the negative environmental impact of pyrometallurgy and its high energy consumption, and because pyrometallurgy is not adaptable to extract metals from the new and leaner polymetallic resources.

The development of new hydrometallurgical processes for the recovery of cobalt, nickel and manganese from new polymetallic ores while keeping as low as possible the environmental footprint and the cost of the process is therefore a central concern. While cobalt and nickel separation in acidic chloride and sulfate media is easily performed by liquid-liquid extraction by using the well-established Cyanex® 272 extractant (bis-(2,4,4-trimethylpentyl) phosphinic acid), the separation of manganese from cobalt-nickel by solvent extraction is more difficult. Such a separation is presently performed using precipitation unit operations, which may increase the complexity of the process and its cost. The development of new extracting agents and the corresponding flowsheets incorporating them is particularly important to achieve the desired selectivity. Chagnes et al. [START_REF] Omelchuk | Effects of structural changes of new organophosphorus cationic exchangers on solvent extraction of cobalt, nickel and manganese from acidic chloride media[END_REF][START_REF] Omelchuk | Investigation of aggregation and acid dissociation of new cationic exchangers for liquid-liquid extraction[END_REF][START_REF] Omelchuk | New cationic exchangers for the recovery of cobalt(II), nickel(II) and manganese(II) from acidic chloride solutions: Modelling of extraction curves[END_REF] recently published papers on the use of the new extracting agents reported in Figure 2 for the extraction of Ni(II), Co(II) and Mn(II) from acidic chloride media by two new extractants.

(a) (b) Such an observation can be explained by a decrease of the pKa values due to the presence of oxygen atoms in the alkyl chains of the extractant [START_REF] Beltrami | Development of New Cationic Exchangers for the Recovery of Uranium (VI) from Concentrated Phosphoric Acid[END_REF] . Extraction properties of BiDiBOPP and IPA are very close as they have similar chemical structure. Therefore, no significant influence of the branching of the alkyl chains of the organophosphorus compounds on the extraction properties of Co(II), Ni(II) and Mn(II) is observed. The decrease of the pH of extraction when Cyanex® 272 is replaced by BiDiBOPP and IPA is interesting potentially for reducing the extraction process operating cost.

Indeed, solvent extraction is used to recover metals from leaching solutions which are usually acidic. Therefore, it is necessary to add an alkaline reagent to increase the pH of the leaching solution in order to perform the extraction. For instance, the use of Cyanex® 272 to extract Co(II) and Ni(II) requires an increase of the pH of the leach solution from around 1-2 to 4.2 and 6.5 respectively. By replacing Cyanex® 272 with BiDiBOPP or IPA, less neutralizing alkaline reagent should be needed as it will only be necessary to raise the pH from 1-2 to 2.3 and 3, respectively. Based on the above results, it is therefore possible to envisage the flowsheet proposed in Figure 4 to separate Co(II)-Ni(II)-Mn(II) mixtures in acidic chloride media without performing any precipitation operation. For example, in recycling cathode material from lithium-ion batteries, there are no elements present other than Co, Ni and Mn. For ores, additional treatment might be needed because of the presence of other impurities such as iron that must be removed.

LITHIUM EXTRACTION

With regard to primary extraction, lithium is produced commercially from two main sources, i.e. mineral ore such as spodumene (LiAlSi2O6) and petalite (LiAlSi4O10), and nature mixed alkali/alkaline earth brines. New minerals are also being considered such as Jadarite which is a lithium sodium borosilicate. The other source of lithium are brines; subsurface brines have become the dominant raw material for lithium carbonate production worldwide because of lower production costs compared with the mining and processing costs associated with hard-rock ores. Nevertheless, by considering the increasing demand for lithium and lithium salts, the current production levels of this metal should be further improved. Thus, lithium ores need to be considered as mainstream resources. Among the different lithium ores, the mineral spodumene is one of the most interesting sources of lithium readily available in Australia.

Two patented processes are used for recovery of the lithium from spodumene [START_REF] Davidson | Recovery of lithium from low-grade ores[END_REF](12)[START_REF] Dunn | Cyclical vacuum chlorination processes, including lithium extraction[END_REF] :

-In the first process, limestone and spodumene concentrates are mixed and calcined. The alpha-spodumene is thus transformed into the beta form while decrepitation occurs and the CaCO3 is decomposed into CaO. Ideally, part of the resulting CaO reacts with the SiO2 in the spodumene to form 2CaO-SiO2 or 3CaO-SiO2 and the Al2O3 reacts with the Li2O to form LiAlO2. The calcined material is leached with water, LiOH coming off in solution.

-In the second process, an acid-leach route is implemented after roasting the spodumene concentrate for conversion of the naturally occurring alpha-spodumene to the betaspodumene since alpha-spodumene is a refractory material in acidic leaching. Beneficiation of spodumene ores (2.8-4.2% Li2O) are performed by using gravity, heavy media, flotation, and magnetic separation processes to produce technical-grade lithium concentrates or chemical-grade lithium concentrates depending on market demand. In the acid leach process, the concentrate is roasted at 1070-1090 °C to convert the spodumene to the beta form. The inversion is accompanied by severe decrepitation, which leaves the spodumene very finely pulverized and thus facilitates the extraction of the lithium. The calcined ore is heated with H2SO4 to approximately 250 °C, and then water is added at 90 °C to dissolve lithium sulphate, which is highly soluble in water [START_REF] Pillot | Battery Market Development for Consumer Electronics, Automotive, and Industrial: Materials Requirements and Trends -Presentation given at the Advanced Automotive Battery Conference 2014 -AVICENNE Energy[END_REF] . Impurities such as Fe, Al, Mg, Ca, etc., are removed as hydroxides at pH 12 by adding NaOH or precipitated using limestone due to low cost and solid-liquid separation challenges. The purified leach liquor is afterward treated using ion exchange to concentrate lithium. Carbonation of the lithium-rich solution is thereafter applied to precipitate lithium carbonate. Both battery-grade (99.5%) Li2CO3 and Na2SO4 as a by-product are produced from this process. In certain cases, an electrodialysis module can be included to produce a LiOH solution from purified Li2SO4 solution obtained after impurities are removed by precipitation and ion exchange. The LiOH solution generated is then heated to concentrate Li values and a crystallization stage is finally conducted to yield LiOH•H2O. High purity Li2CO3 and LiOH•H2O of >99.9% grade can be produced from this process.

Lithium recovery from brines relies on solar evaporation before a refining stage consisting of the implementation of solvent and/or resin extraction steps in order to produce battery-grade lithium salts. Solar evaporation is very cheap, but it requires more than one year between starting the operation and the first grams of lithium salt produced. In order to reduce the production time, two innovative processes have been recently developed by Eramet (14)(15) and Solvay-Tenova [START_REF] Lipp | LISX TM A new SX Technology for Lithium Recovery[END_REF] [START_REF] Cohen | Technological Advances, Challenges and Opportunities in Solvent Extraction from Energy Storage Applications[END_REF] :

Eramet Process

ERAMET started developing a lithium production project in 2016 in order to extract lithium from brines located in the Andean cordillera area (Salta, north-western Argentina). The resources of the Centenario-Ratones deposit are very significant and justify a large industrial production of 20,000 tonnes of lithium carbonate for several decades. The innovation of this process is based on the use of very selective sorption material towards lithium implemented in a solid-liquid extraction stage, solvent extraction and membrane processes. In 2016, the ERAMET Lithium project enters the final stages of its development.

In this process, the brine is pumped from a depth of 200 m and is fed into the lithium extraction unit which consist in a solid/liquid extraction by means of an appropriate sorbent (LiCl.2Al (OH)3, nH2O) patented by Eramet [START_REF] Boualleg | Procédé de préparation d'un matériau absorbant mis en forme en l'absence de liant et procédé d'extraction de lithium à partir de solutions salines utilisant ledit matériau[END_REF] . During this step, lithium is selectively extracted towards calcium, magnesium, boron and sulphates. The brine after lithium extraction is reinjected in the brine field aquifer via infiltration so that the water balance of the brine field is not affected (unlike with conventional solar evaporation). After elution of the sorbent loaded with lithium, the solution is concentrated by means of reverse osmosis and the resulted concentrated solution is afterwards purified by using solvent extraction to remove boron and ion exchange extraction in order to remove traces of calcium and magnesium before adding sodium carbonate in order to produce lithium carbonate salts for glass, ceramic and greases industry as well as lithium-ion battery industry.

Solvay-Tenova Process

Solvay and Tenova have recently developed a new technology for the recovery of lithium from brine based on the use of Cyanex® 936 as extraction solvent, which exhibits a good extraction efficiency for lithium (80% at pH 9) and high selectivity towards potassium, sodium and bore. This solvent extraction stage is combined with membrane technologies and electrolysis. Calcium and magnesium are first removed from the brine by a membrane process. The brine without magnesium and calcium is afterwards sent into an electrolysis cell in order to generate chlorine which is used to produce hydrochloric acid used for stripping in the solvent extraction process. The PLS containing lithium (without calcium and magnesium) is sent to the solvent extraction stage that relies on the use of Cyanex® 936. After scrubbing and stripping with hydrochloric acid, lithium chloride is directly produced, or the stream can be sent to the precipitation stage with soda ash in order to produce lithium carbonate or to the electrolysis stage in order to produce hydrochloric acid and lithium hydroxide. This process is also interesting because it allows extracting lithium without affecting the brine field like with the Eramet process, it avoids any production delay due to solar evaporation, and because it is very versatile since it permits to produce different products without significantly changing the process.

Figure 2 .

 2 Figure 2. Chemical structure of (a) bis(1,3-dibutoxypropan-2-yl) phosphoric acid (BiDiBOPP) and (b) bis(1,3-diisobutoxypropan-2-yl) phosphoric acid (IPA).

Figure 3

 3 Figure 3 shows the extraction isotherms of Co(II), Ni(II) and Mn(II) from acidic chloride solution by Cyanex® 272 and the two extractants synthesized in the present work, i.e. BiDiBOPP and IPA. The presence of oxygen atoms in the chemical structure of BiDiBOPP and IPA shifts the extraction curves of Co(II), Ni(II) and Mn(II) towards the low pH values since pH of half extraction pH1/2=3.8, 4.2 and 6.5 for Co(II), Mn(II) and Ni(II), respectively, when Cyanex® 272 is used whereas pH1/2=2.3, 1.5 and 2.5 and pH1/2=2.3, 1.5 and 3 for the same metals with BiDiBOPP and IPA respectively.Such an observation can be explained by a decrease of the pKa values due to the presence of oxygen atoms in the alkyl chains of the extractant[START_REF] Beltrami | Development of New Cationic Exchangers for the Recovery of Uranium (VI) from Concentrated Phosphoric Acid[END_REF] . Extraction properties of BiDiBOPP and IPA are very close as they have similar chemical structure. Therefore, no significant influence of the branching of the alkyl chains of the organophosphorus compounds on the extraction properties of Co(II), Ni(II) and Mn(II) is observed. The decrease of the pH of extraction when Cyanex® 272 is

Furthermore, it isFigure 3 .

 3 Figure 3. Extraction efficiency of (a) Co(II), (b) Ni(II) and (c) Mn(II) by Cyanex® 272, BiDiBOPP and IPA diluted in kerosene as a function of equilibrium pH. Temperature=25 °C; phase volume ratio Vorg/Vaq=1; chloride concentration=1 M.

Figure 4 .

 4 Figure 4. Proposed flowsheet for separation of Co, Mn and Ni

High purity grade for: • Pharmaceuticals • Glass and ceramics • Steel continuous casting Technical-grade products for:

		Lithium grease	Air conditioning
	• Steel continuous casting
	• Aluminium melting
		• CO2 scrubbing
	Battery-grade for:	• Steel continuous casting
	• Li-ion batteries (secondary,	• Aluminium melting
	rechargeable, batteries)
		Battery-grade for:
		• Primary (non rechargeable) lithium
		batteries
		• Li-ion batteries (secondary,
		rechargeable, batteries)

Other Li halogenides LiClO4, LiF, LiI ..