A distributed approach to File Management in IMA2G

Transcription

1 Copyright 2011 SAE International 11ATC-0436 A distributed approach to File Management in IMA2G Silvia Larghi, Marco Villa, Michele Tumminelli, Antonio Ottolia, Massimo Traversone Selex Galileo Nerviano (MI) - Italy ABSTRACT The SCARLETT European Research Project has the goal to define, develop and validate the concepts of the next generation of IMA (IMA2G). Enhanced File Management capability is central to support next generation IMA Platform properties and the increasing usage of memory mass storage. IMA2G Applications require access to data stored on mass memory independent from their physical location across the Platform; Platform-wide File Services are required. We provide, in the framework of the SCARLETT project, a distributed approach to File Management, which meets the IMA2G requirements. The proposed design aims to move from a module-centric File Management, typical in IMA1G, to a Platform-centric File Management based on a distributed file stack. After examining existing IMA standard solutions concerning File Management, an overview of the Platform File Management architecture is given. We present and discuss the key design drivers: a distributed approach, localization, the communication protocol between File Clients and File Servers, IMA1G compatibility and reuse, replication and linked error handling aspects, health monitoring, management of write access and network topology considerations. A demo implementation is described. INTRODUCTION Integrated Modular Avionics (IMA) is currently used in various classes of modern aircrafts. It provides a platform of integrated and interoperable hardware and software resources able to host applications which perform aircraft functions [1]. An IMA platform allows several hosted applications to share physical and logical resources, such as processor, memory, software, data, etc.. Functional isolation and independence is achieved by means of robust partitioning and resource sharing is supported by Health Monitoring and Fault Management at platform and applications level [1]. The first generation of IMA (IMA1G) has been introduced in Europe through joint research efforts based on European funded research projects PAMELA, NEVADA and VICTORIA [2, 3]. The leading aerospace industry demands were: to increase operational reliability, to reduce cost of avionics parts and maintenance, to reduce weight, thus augmenting fuel efficiency, to reduce volume and power consumption [2, 6]. The ASAAC (Allied Standard Avionics Architecture Council) Consortium, formed by European government and industry representatives (UK, France, Germany), was established with the objective to explore the IMA concepts, define and validate a set of Open Architecture Standards, Concepts & Guidelines for Advanced Avionics Architecture applicable to new aircraft and upgrade programs. The main drivers were: reduction of life cycle cost of avionics systems, improvement of operational performance, improvement of mission performance [4, 5]. As result of research activity, IMA1G has been applied to a limited range of aircraft functions, demonstrating to be cost-effective with respect to traditional federated avionics. The key is IMA1G replaces numerous separate processors and line replaceable units (LRUs) typical of the classical federate avionics architectures with fewer more centralized processing units, introducing elements and modules common to different computers. IMA1G is currently onboard the A380, A400M and B787 aircrafts: the number of processing units in the new A380 is half that of previous generations and reductions in airline operating costs are expected [2, 6]. Page 1 of 12

2 The SCAlable & ReconfigurabLe Electronics, platform and Tools (SCARLETT) European Research Project [2] has the goal to define, develop and validate the concepts of the next generation IMA (IMA2G). The SCARLETT vision of IMA2G is a scalable, reconfigurable, fault-tolerant driven and secure new avionics platform, namely DME: Distributed Modular Electronics [2]. Considering the current IMA1G as a starting baseline, SCARLETT enables progress towards a full IMA concept by introducing the DME platform. The DME platform is Scalable: capable to be adapted to the needs of various aircraft types, large numbers and different types of applications, and Reconfigurable: with reconfiguration, the use of shared resources can be optimized at platform level. From software side, SCARLETT offers platform dedicated services to handle the IMA2G platform, in addition to the classical IMA1G OS services. The Platform Services are implemented through the Middleware concept. SELEX Galileo contributes to SCARLETT providing Platform Services for File Management and the relevant Middleware component. In the following sections, we give general information about the SCARLETT project and describe the DME platform software component introducing the concept of Middleware. Following, we make considerations on existing standards concerning File Management. We define the objectives of the SELEX Galileo research contribution and give an overview of the Platform File Management preliminary architecture. We present and discuss key design drivers. A demo implementation is described. Finally we give a summary of open questions and future work. SCARLETT AND THE MIDDLEWARE SCARLETT [2] is a collaborative research project founded by the European Commission 7 th Framework Programme (FP7/ ) [7]. The SCARLETT consortium, coordinated by Thales, joins 38 partners from 16 countries, with complementary profiles, collecting a broad range of expertise: Large Industrial Companies, Public Research centers, Industrial Research centers, Universities, SMEs [2]. SELEX Galileo [8] is one of the SCARLETT partners. By defining the DME platform, SCARLETT is able to meet its drivers: to provide a scalable solution, to define a minimal set of modules, to increase the number of supported functions, to develop new standards for the 2nd generation IMA, to provide associated process and toolset, to demonstrate fault tolerance and reconfiguration [2]. By the end of the project, SCARLETT will produce four demonstrators of the DME platform capabilities. The SELEX Galileo Distributed File Management will support the High Performance Data Distribution demonstrator. The DME platform introduces the Middleware software to provide platform level services. The Middleware is implemented on top of the Operating System local to the DME hardware components. Its purpose is to enable IMA2G typical interoperability, allowing the provision of the same service with the same behavior in such a way that it is independent from the physical location of the requesting applications, i.e. the DME hardware component that hosts the application, independent from the DME hardware component type, if applicable, and the Operating System hosted and independent from the location of the requested hardware resources, e.g. mass storage in the case of File Management. In SCARLETT, the terms Platform Software or Platform Services refer to the DME platform functional software component. The Middleware and the Operating Systems hosted on the various DME hardware components indicate instead physical software components that, integrated with hardware, are the concrete implementation of the Platform Services. Platform Services are distributed on all DME hardware components which compose the DME platform. The Middleware provides applications with the entry points of the Platform Services. Platform Services are classified at two levels according to their scope, which can be the overall DME platform or a single DME hardware component; Platform Services include in fact Module Services. Platform Services are also classified according to their privilege, whether they support Avionic applications or Platform Management applications (including module management). In IMA1G, the programming interface for the Avionic applications provided Module Services and was called API or APEX. ARINC 653 Parts 1 and 2 [9,10] provide an avionics standard APEX. EXISTING STANDARDS In this section we examine how existing IMA standards deal with File Management. ARINC 653: The ARINC Specification 653 Part 2 [10] includes the definition of extended services that are considered optional in safety critical embedded applications. Among these, there are file system services. The ARINC standard defines a file system as a general purpose, abstract way of managing data storage [10]. The file system provides services which can be used by multiple Page 2 of 12

3 partitions to access the storage media. One or more types of storage media may be supported depending on implementation. The services provided may support flight critical applications, on condition that design and implementation present the necessary characteristics of reliability and integrity [10]. The ARINC 653 file system is based on POSIX [11] and provides similar behaviour to corresponding POSIX services [10]. In accordance to the ARINC standard The ARINC 653 file system should not violate time and space partitioning requirements, this include prevention of modification of file data not owned by the partition. Storage device identification, access rights, space allocation, file descriptor allocation and volume name aliasing (the name used by an application to reference the volume) are contained in configuration tables. These items are applied to a portion of a storage device referred to as a volume [10]. ARINC 653 notes, in a commentary section, that a file system implementation can be local to the module or part of a network [10]: it is also observed that File systems with storage non resident within the core module (with the accessing partitions), can be more complex (e.g. network file system) to ensure characteristics such as latency, availability, volatility, integrity and ARINC 653 based access rights [10]. ASAAC: The ASAAC standard is published as UK MoD standard [12, 13] and NATO standard [14]. The ASAAC Software Architecture is a three-layer stack where each of the three layers is defined in terms of its dependency or independency on the aircraft system and on hardware. The Application Layer is dependent on the aircraft but independent on hardware, the Operating System Layer is independent on both aircraft and hardware and, finally, the Module Support Layer is independent on the aircraft but depends on hardware. The three-layer stack software is deployed on top of each Common Functional Module hardware. The full Software Architecture defined by ASAAC is very articulated and comprises multiple standard interfaces and software components with standard semantics. Examples of interface definition: the APOS is the Application to OS interface, the OLI is the Operating System Logical interface [13]. In an ASAAC System, the Mass Memory Storage capability is provided by a dedicated type of hardware: the Mass Memory Module (MMM). The MMM provides file access capability and storage capability to the other Common Functional Modules (CFM). Depending on implementation, a MMM may host several classes of file. CFMs are able to access to files stored on a MMM through servers provided by the MMM itself. Servers are hosted on MMMs within a specific software layer which depends on the software layer hosting the requester on the other CFMs. Direct file access, in fact, can be performed on MMMs only, while the other CFMs can access to remote files through the OLI. The ASAAC Mass Memory management does not support management of remote CFM file access rights. This is part of the Security Management policy [12, 14]. The standard distinguishes between Local File Management, which is performed on MMMs, and Application File Access (remote with respect to MMMs). File access and file handling services are provided by an APOS specific to the MMM. Applications on a remote CFM can access a file establishing communication with an MMM: the requesting Application Process on the remote CFM represents the client and an Application Process on the MMM is the server. Communication between client and server is based on Virtual Channels (VCs) and a request/reply mechanism. The MMM executes the requested APOS service and sends the result to the requesting Application. Definition of the interface between the Application Process (on remote CFM) and Application File Server (on MMM) is implementation dependent [12, 14]. In conclusion, both ARINC 653 and ASAAC provide file system management suitable for application level partitions. ARINC 653 addresses remote file access aspects, at commentary level, but does not provide a specification for a network file system. The ASAAC standard specifies remote file access and relevant multi module coordination (client/server) introducing a distinction between Local File Management (on MMMs) and remote Application File Access: File Access and File Handling services are specific to the hardware module where the mass storage is physically located. As anticipated in the previous section, SCARLETT aims to a further level of interoperability typical of IMA2G, which implies the provision of the same service with the same behavior independent from the physical location of the requesting applications, from the type of underlying hardware and from the physical location of the mass storage. THE SELEX GALILEO RESEARCH OBJECTIVES Typical IMA1G implementations of File Management are usually based on a local file stack, so that a file system is used locally. Applications need to be co-located on the same module of the mass storage hosting the file system and are provided with file services by the local OS. In such implementation, applications have no simple way to access to remote mass storage: it is implementation dependent. Finally, according to ARINC 653 standard, Files can be read by multiple partitions but written to by only one partition (i.e. the owner partition). Access rights are assigned at configuration time and cannot be changed run-time. Page 3 of 12

4 An increasing usage of mass memory storage is foreseen in IMA2G due to evolution of technology which enables new and complex functions to be introduced at application level. The capability to store and retrieve data in memory is also at the bases of innovative platform properties introduced in SCARLETT, such as reconfiguration. In SCARLETT a load file may contain a configuration table, an application software or a database, as an example. IMA2G applications need simple access to remote mass storages and file services should be provided at DME platform level. The goal of the SELEX Galileo contribution to SCARLETT is moving from a module oriented to a platform oriented approach to File Management. It is proposed in SCARLETT to adopt a distributed file stack (in contraposition to the typical IMA1G local file stack). The distributed file stack has the following characteristics: many file systems may be used by many applications, applications and mass storage items may be located on different hardware modules, new platform-wide Middleware file services are provided to applications instead of OS-centric local file services, a classical file management API is provided to applications, multiple partitions can have write access to a volume and each file can be locked/unlocked for writing by an application at run-time. THE FILE MANAGEMENT ARCHITECTURE The SELEX Galileo contribution is focused on the concept definition and architectural design of the overall platform File Management and the design and implementation of the File Management Middleware components: File Clients, File Servers, Communication protocol between File Clients and File Servers, File Management Platform Services API. File Clients provide applications with the entry points of the platform services dedicated to File Management. They are built on top of the OS local to the DME component where the requesting application is hosted. Files are contained in several file systems physically located on DME components local or remote with respect to the requesting application. File Servers provide file system services to the requesting File Clients. File Servers are built on top of the OS local to the DME component where the relevant file system is physically hosted. It is assumed that the OS underlying File Clients and Servers Middleware components are compliant with the ARINC653 Specification [9]. It is also assumed that file systems are compliant with ARINC653 P2 [10]. Instances of File Clients and File Servers, are distributed on DME components across the DME platform. Figure 1 shows an example of communication flow for a File Management operation, identifying relationships between the involved items. We introduce a few rules, definitions, and design decision: Figure 1 File Management operation flow For each application who wants to use the File Management there is one instance of File Client. A physical mass-storage is partitioned in one or more volumes (a volume being defined as the allocation of a portion of mass storage); we assume in SCARLETT that one volume is associated to one file system. For each volume there is one instance of File Server. The File Server is co-located with the file system. Page 4 of 12

5 Software components located on one DME hardware component can communicate to remote software components, located on a different DME hardware component, through the SCARLETT Communication Manager, exchanging messages across the network. AFDX technology [15] is the baseline in SCARLETT for IMA2G network. SCARLETT provides platform services for inter partition communication. For File Management purpose it is assumed that platform communication services are compliant with ARINC653 [9]. SELEX Galileo defines and implements a protocol for communication between File clients and Servers built on top of ARINC653 Queuing Ports semantics and interface [9]. The platform File Management provides to applications 16 Platform File Services (PF Services) to operate File Systems independent from their physical location. PF Services are provided for file handling (open, close, remove, ), directory handling (make_directory, remove_directory, ), file content access (read, write, ). 2 additional PF Services are provided to handle locking/unlocking of files for writing. A PF Service to initialize File Clients is also foreseen. In order to promote IMA2G interoperability, the choice in SCARLETT is to create a new API for File Management at platform level, implemented by Middleware software on top of the Operating Systems local to the various DME hardware components; the Middleware File Management components, thus, can benefit of the existing Operating Systems API, bringing new features, such as distributed access and replication. A DISTRIBUTED APPROACH In this section we describe more in detail the flow of a File Management operation involving distributed file access. Let s assume, in Figure 1 example, that the physical mass storage located on DME component 2 holds a File System with associated logical volume name c:. Request flow: Application 1 calls a platform File Service to read file Selex_1 on c: (1.). It does not know the actual physical location of the file. File Client 1 makes the following actions: resolves the physical localisation of the file, performs marshalling of input data and packs a read file call message. The call message is transmitted to the local Communication Manager (2.) and across the network (3.), (4.), through the appropriate remote Communication Manager, to File Server 2 (5.), which decodes the message and calls the local IMA1G Read File service provided by File System 2 (6.). Reply flow: File Server 2 gets the reply from File System 2 (7.), performs marshalling of the reply data, packs a reply message and sends it across the network to File Client 1, who is waiting (8.), (9.), (10.), (11.). Finally File Client 1 can transmit the reply to the calling application (12.). One File Client can address several File Servers managing different volumes. Whether the communication is to be handled locally or through the network is resolved by the Communication Manager, see Figure 2. Figure 2 local and remote file access Page 5 of 12

6 The adopted distributed approach introduces transparency at application level: applications use the same File Management API independent of their physical location, while the propagation of request and reply messages across the network is hidden from the applications point of view. Development of applications is not dependant on deployment of the application partitions across the DME platform. LOCALIZATION The File Client s Localisation Manager is able to identify the physical location of the files by means of their logical name, which is required in input by platform services to open a file. Logical file names are composed by an absolute path defined as follows: absolute-path: / volume-name / local-path local-path: file-name In our example: c:/selex_1. directory-name[ / [local-path]] Volume names are associated to APEX port pairs (source/destination) by means of a dedicated Configuration Table. APEX ports refer to the File Server(s) enabled to manage the specified volume. The File Client s Localisation Manager extracts the volume name from the absolute path so that the File Client is able to address call messages to File Servers on the corresponding APEX port(s) and listen to reply messages on the corresponding APEX port(s). On the other hand, each File Server is associated to the File Clients which are enabled to access to it by means of a dedicated Configuration Table, which contains the list of APEX client port pairs (request/reply). THE COMMUNICATION PROTOCOL BETWEEN FILE CLIENTS AND FILE SERVERS The Communication Protocol between File Clients and Servers is based on the Remote Procedure Call model (RPC) [16] (adapted). One thread of control logically winds through two processes: the caller s process (client) and a server s process. The caller process first sends a call message to the server process and waits for a reply message. The call includes the procedure s parameters, and the reply message includes the procedure s results, see Figure 3. Once the reply message is received, the results of the procedure are extracted [16]. Figure 3 File Management RPC message structure Page 6 of 12

7 IMA1G COMPATIBILITY AND REUSE IMA1G compatibility is a technical challenge in SCARLETT; IMA2G architecture and concept should not break existing IMA1G architectures or, at least, the impact should be as minimum as possible. The software architecture adopted for File Management is compatible with IMA1G in that it provides a means to make existing IMA1G File Systems and related Services available to requesting applications independent from their physical location across the platform. This is achieved through the introduction of the Middleware components, File Clients and File Servers, on top of the local Operating Systems. These new components are hosted in ARINC 653 partitions which are independent with respect to the IMA1G File Systems provided within the local Operating Systems. File Servers are ARINC 653 partitions, File Clients are libraries to be linked with applications, which in ARINC 653 approach are de-coupled from OS partitions. Therefore the distributed File Management provided by Selex GALILEO for SCARLETT extends IMA1G without breaking the local File Systems internal structure. The adopted approach allows re-use of existing IMA1G File Systems and Services, provided that they are compliant with ARINC653 P2 [10] as highlighted in the previous sections. REPLICATION Replication is a key aspect of the Selex GALILEO distributed File Management. It serves to increase File Systems availability. It is also fundamental, in SCARLETT, to support reconfiguration capability. Replication consists of maintaining consistent copies of a File System into different physical locations. Figure 4 use case shows the flow of a File Management operation with replication. The physical mass storage located on DME component 2 holds File System 1 and the physical mass storage located on DME component 3 holds a copy of File System 1. Application 1 requests to access to File System 1 through File Client 1 (1.). Information on the replication list, i.e. the list of all File Servers which serve copies of the same volume, is held in the File Management Configuration Tables. There is one replication list for each volume; each volume can exist in 1 single copy or more copies. File Client 1 knows from Configuration Tables that n (in Figure 4 example n=2) physical copies of File System 1 exist, because n File Servers are associated to the logical volume name relevant to File System 1, one for each physical copy of File system 1 (replicate). A call message is addressed to both File Server 1 which serves File System 1 (flow = (2.).. (6.)) and File Server 2 which serves File System 1 copy (flow = (2a.).. (6a.)). Both servers send their reply to File Client 1 (flows = (7.).. (11.) and (7a.).. (11a.)) which can transmit a reply to the calling application (12.). Figure 4 Replication use case, n=2 replicates We implement replication with strong type consistency: when application requests have the effect to modify a File System, updates are propagated at the same time (considering queuing and network latency) to all copies of File System. It is assumed in SCARLETT that all File System copies are initially consistent, being the alignment guaranteed by PowerOnSelfTest. Page 7 of 12

8 Figure 5 shows the properties of replication in case one server is not available. Figure 5 Replication use case, n=2 replicates, server not alive In Figure 5 specific example, after transmitting a call message to File System 1, File Server 1 becomes not alive (X.); this may happen due to a network fault, as an example, or desired due to a reconfiguration action. As a consequence, File Client 1 receives 1 reply message only, from File Server 2 which is still alive, and is still able to transmit a reply to the calling application (12.). Therefore, use of replication may support platform reconfiguration capability, as anticipated and, augmenting File Systems availability, aids smooth degrade of capability of the overall system in case of servers not available due to faults. Use of replication, however, should be carefully planned as the more replicates are used, the more network band allocation is necessary. ERROR HANDLING WITH REPLICATION In presence of replication, the File Client receives replies from all File Servers involved in the replication list and transmits only one reply to the calling application, see Figure 4 as an example: File Client 1 collects replies from File Server 1 and File Server 2 and transmits only one reply to application 1. Following a request to access a specified volume, the File Client compares the replies obtained by all File Servers involved in the replication list associated to that volume. If the replies are different, all File Servers involved in the replication list are declared not available due to functional failure and an error message is returned to the calling application. Timeout replies, meaning that the File Server is not available in that moment, are not considered in this algorithm. See the example in Figure 5: File Server 1 is not available; File Client 1 gets a timeout from communication with File Server 1 and a reply from File Server 2. File Client 1 is therefore able to transmit to application 1 a response with the reply obtained by File Server 2. From the application point of view, there is a loss of capability only when all File Servers of the replication list are no longer available; in this case a timeout information is transmitted to the calling application. Generalising, until at least one File Server of the replication list is available, applications do not need to know about the status of all other File Servers. THE SERVERS MONITORING AGENT The servers status ( server up or not available ) is monitored by the Servers Monitoring Agent (SMA). This is an independent partition which can be located everywhere across the DME platform. It collects periodically keep alive messages from all File Servers and informs periodically File Clients on File Servers status. In addition File Clients inform the SMA if they have detected a functional failure on File Servers belonging to a replication list in accordance to the error handling algorithm previously described. In this case all File Servers belonging to the replication list change status to not available. Page 8 of 12

9 In this work, it is not possible, for File Servers, to recover from a not available status. The current assumption in SCARLETT is that it is up to the aircraft manufacturer to decide when and how to recover, including the realignment of the involved File System contents. MANAGEMENT OF WRITE ACCESS Write permission on a specified volume is assigned statically to applications in Configuration Table. One single volume can be accessed in write mode by multiple partitions. If a partition has write permission on a volume, a further locking mechanism, on single file bases, is offered to applications through the File Client, so that files can be locked/unlocked for writing by an application at run-time. The concept of write token is managed by the File Server, which will discard write requests on files which have not been locked for writing by the requesting application. Applications cannot write to files belonging to a volume where they are not allowed to write. CONSIDERATIONS ON NETWORK TOPOLOGY Communication between File Clients and File Servers and with the Servers Monitoring Agent is based on ARINC 653 APEX ports. In this section we show the network topology relevant to File Management and calculate the number of APEX ports which are to be configured to use File Management. Figure 6 represents C File Clients, one per each application who wants to use the File Management. There are V volumes, and each of them can be replicated up to R times; considering the worst case, where each volume has R replicates, V R File Servers are necessary. Finally there is 1 partition acting as Servers Monitoring Agent. Sizing: Figure 6 File Management network topology Each File Client has an APEX ports pair (source/destination) for each File Server it has to communicate with, plus one APEX port pair for communication with the SMA, therefore: Each File Client ports count = 2 V R + 2, considering each File Client addressing all File Servers (worst case); there are C File Clients. Each File Server has an APEX ports pair (source/destination) for each File Client it has to communicate with, plus one single APEX port to communicate its status to the SMA, therefore: Each File Server ports count = 2 C + 1; there are V R File Servers. The Servers Monitoring Agent has an APEX port for each existing File Server to receive information on the server status, an APEX port for each File Client to receive information on errors and one single sampling APEX port (multicast) to propagate the server status information to File Clients, therefore SMA ports count = V R + C + 1. Page 9 of 12

10 Total ports count = 4CVR + 3C + 2VR + 1. Example: 2 volumes, each being replicated twice V=2, R=2; 4 File Clients, addressing all servers C = 4; Each File Client ports count = 10; Each File Server ports count = 9; Servers Monitoring Agent ports count = 9; Total ports count = 85. IMPLEMENTATION In this section we describe a demonstration based on a reduced version of the File Management (4 platform File Services, no SMA, no management of write access). Objectives of this demonstration were: to prove distributed access to remote File Systems works, to prove communication between File Clients and File Servers works, to prove replication. The environment for the demo is built as follows: 1 File Client located on a commercial PPC hardware module, 2 File Servers, File Server 1 and File Server 2, located on two different PPC commercial modules, remote with respect to the File Client hosting module. The PPC module hosting File Server 1 is equipped with an USB pen drive holding a file system (File System 1, 1 volume). The PPC module hosting File Server 2 is equipped with an USB pen drive holding a copy of File System 1. All hardware boards are connected on a network (AFDX technology). The test application continuously executes a loop of PF_OPEN_FILE, PF_WRITE_FILE, PF_CLOSE_FILE, PF_OPEN_FILE, PF_READ_FILE, PF_CLOSE_FILE addressing file c:/selex1, located on File System 1 (and its copy). Execution shows that the File Client Localization Manager identifies a replication list composed by 2 File Servers associated with c: RL(c:) = (REMOTE_SERVER_1, REMOTE_SERVER_2) and all commands are completed successfully. Exploration of the network status shows that, for each command executed, the network communication is active between CLIENT and SERVER 1 and between CLIENT and SERVER 2. Therefore, the File Management is able to access to remote File Systems executing commands which are propagated to both existing File System copies. A second step of the demonstration foresees that, while the loop of PF Services is being executed, a network cable connecting File Server 2 to the network switch is detached manually, thus creating a network fault. All commands are completed successfully, although exploration of the network status shows in this case that, for each command executed, the network communication is active between CLIENT and SERVER 1 only, from the moment when SERVER 2 was detached. It has to be noticed that commands are still completed successfully because at least one File Server is up (SERVER 1 in this case), in accordance with the philosophy of replication. At this point the loop of platform File services is being executed successfully with communication active between File Client and File Server 1, while File Server 2 is no longer available. The network cable connecting File Server 1 to the network switch is detached manually. From this point in time, exploration of the network status shows NO active communication between File Client and both File Servers and, as expected, operations requested by the File Client complete with error, in fact there are no remaining active File Servers. FUTURE WORK Integration of the platform distributed File Management within the SCARLETT demonstrator will give the opportunity to evaluate performances and behaviour of the Communication Protocol between File Clients and File Servers, currently based on the RPC model. Initial (simplified) versions of NFS [17] might be considered as a possible evolution, although feasibility and advantages/disadvantages are to be considered. The File Management design foresees dedicated Configuration Tables. These might in future be merged into an overall Platform Configuration Table. As well the Servers Monitoring Agent which is specific to File Management might in future be merged within a centralised IMA2G Health Monitoring. The present File Management design allows multiple partitions to access files in write mode and offers a mechanism to lock and unlock files for writing run-time. The responsibility of the correct and safe use of these features is currently left to the applications themselves. For the future IMA2G an overall refinement of access rights policy and write permission management is advised in accordance to the perceived needs. Concerning replication, once a File Server part of a replication list becomes not available, the present File Management design does not foresee a recovery mechanism. The problem behind is to maintain consistency of the relevant file system content with respect to its copies, which may be updated because their servers remain active. The current assumption is that the overall file systems content is Page 10 of 12

11 reconciled manually at maintenance time. The problem of consistency of replicates, studied and discussed for what regards distributed systems, represents a challenge in the area of embedded systems for avionics. Still concerning replication, a policy for error handling is proposed with the present work to manage multiple replies received by replicates. This policy might also be refined for future in accordance to the perceived needs. SUMMARY/CONCLUSIONS In this work we first summarized what ARINC 653 and ASAAC IMA standards foresee concerning File Management, concentrating on remote file access aspects. We described then a platform-wide File Management architecture we provide for the SCARLETT European research project, suitable to be used in the next generation IMA (IMA2G). We focused on the key design aspects. The platform File Management architecture is based on a distributed approach. We explained how the distributed approach brings a level of interoperability not specified by the existing standards examined, but typical of IMA2G: the same Platform File Services are provided to applications, independent from their physical location. This allows transparency from applications point of view; furthermore development of applications is not dependant on deployment of the application partitions across the DME platform. The physical location of files is identified by means of their logical name while propagation of application s requests across the network is hidden to the applications themselves. We defined a network communication protocol based on adaptation of RPC. We put in evidence that the platform File Management design is compatible with IMA1G file system implementations and allows their reuse. In order to increase file systems availability and support typical IMA2G properties such as reconfiguration, we introduced replication and described related error handling aspects. We introduced the Server s Monitoring Agent as health monitoring capability specific to File Management. We then explained how write access is managed with the distributed approach. We provided a method for network sizing in terms of calculation of APEX ports number necessary to File Management, giving an example. Finally we described a demo implementation and introduced possible future work. REFERENCES 1. DO-297: Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, 2005, RTCA Inc Joseph Huysseune, Philippe Palmer, NEVADA-PAMELA-VICTORIA: Towards the definition of new aircraft electronic systems, Air & Space Europe, Volume 3, Issues 3-4, May-August 2001, Pages , ISSN , DOI: /S (01) ( James W. Ramsey, Integrated Modular Avionics: Less is More, Approaches to IMA will save weight, improve reliability of A380 and B787 avionics, Avionics magazine, 2007 ( 7. CORDIS - Community Research and development Information Service, 7 th framework Programme page ARINC653 P1-2, Avionics Application Software Standard Interface, PART 1 REQUIRED SERVICES, adopted in 2005, published in 2006, Aeronautical Radio Inc. 10. ARINC653 P2, Avionics Application Software Standard Interface, PART 2 EXTENDED SERVICES, 2007, Aeronautical Radio Inc. 11. Portable Operating System Interface standard - IEEE 1003 standards family / ISO IEC MoD Defence Standard 00-74, ASAAC Standards, Part 1: Standards for Software, Issue 2, MoD Defence Standard 00-74, ASAAC Standards, Part 2: Rationale Report for Software Standards, Issue 2, STANAG 4626 Modular and Open Avionics Architectures, Part II: SOFTWARE, Draft 1, Avionics Full DupleX (AFDX) Switched Ethernet network, defined in ARINC SPECIFICATION 664, Aeronautical Radio Inc. 16. RPC: Remote Procedure Call Protocol Specification Version 2, Network Working Group, RFC 1831, R. Srinivasan, Sun Microsystems Inc., NFS: Network File System Protocol Specification, Network Working Group, RFC 1094, Sun Microsystems Inc., 1989 Page 11 of 12

12 CONTACT INFORMATION SELEX Galileo contacts: Silvia Larghi, Massimo Traversone, DEFINITIONS/ABBREVIATIONS APEX API DME IMA IMA1G IMA2G NFS OS PF RPC SCARLETT SMA Application / EXecutive (interface) Application Programming Interface Distributed Modular Electronics Integrated Modular Avionics IMA 1 st Generation IMA 2 nd Generation Network File System Operating System Platform Remote Procedure Call SCAlable & ReconfigurabLe Electronics, platform and Tools Servers Monitoring Agent Page 12 of 12