A Amari

A Mifdaoui

F Frances

J Lacan

D Rambaud

L Urbain

AeroRing: Avionics Full Duplex Ethernet Ring with High Availability and QoS Management

Keywords: Avionics, Real-Time Ethernet, Ring topology, QoS, Performance, Safety. Protocols Costs Reliability Availability Performance Complexity Ethernet Compatibility EtherCAT High Medium High Very High High No PROFINET IRT High Medium High

The avionics standard AFDX has been introduced to provide high speed communication for new generation aircraft. However, this switched network is deployed in a full redundant way, which leads to significant quantities of wires. To overcome this limitation, a new avionic communication network, called AeroRing, is proposed in this paper to decrease the wiring weight, while guaranteeing the required performance and safety levels. AeroRing is based on a Gigabit Ethernet technology and implements a daisy-chain wiring scheme on a Full Duplex ring topology. First, the main features of such a proposal, and particularly the QoS and robustness management, are detailed. Then, numerical results of some Performance Indicators (PI) are illustrated to highlight its ability to guarantee the avionics requirements.

I. INTRODUCTION

The inherent complexity and bandwidth requirement of avionics communication architectures are increasing due to the growing number of interconnected end-systems and the expansion of exchanged data. The Avionics Full Duplex Switched Ethernet (AFDX) [START_REF]Avionics Full-Duplex Switched Ethernet (AFDX) Network[END_REF] has been introduced to provide high speed communication (100Mbps) for new generation aircraft. However, this switched network is deployed in a full redundant way, which leads to significant quantities of wires, and thus increases weight and integration costs. For instance, the A380 contains 500 km of cables [START_REF] Furse | Down to the wire[END_REF].

To cope with these emerging issues, an avionics implementation reducing wires will clearly improve the efficiency and reliability of aircraft through decreasing the integration complexity, and reducing fuel consumption and maintenance costs. Therefore, a new avionic communication network, called AeroRing1 , based on a Gigabit Ethernet technology and implementing a daisy-chain wiring scheme on a Full Duplex ring topology, is proposed in this paper to enhance performance, while guaranteeing a high safety level for avionics applications.

Nowadays, Ethernet technology is considered as one of the most cost effective solutions allowing scalable and arbitrary topologies, and supporting high speed communication and Quality of Service (QoS) requirements. Various approaches have been proposed to guarantee real-time communications on top of Ethernet. The most relevant Real Time Ethernet (RTE) profiles, supporting ring topology and cited in IEC 61784-2 [START_REF]Digital data communications for measurement and control -Part 2: Additional profiles for ISO/IEC 8802-3 based communication networks in real-time applications[END_REF], have been described in [START_REF] Felser | Real-Time Ethernet -Industry Prospective[END_REF]. However, most of these existing solutions are optimized for specific use cases and present some limitations in terms of:

• resource utilization efficiency, since concurrent access to the medium is generally not allowed due to their implemented control mechanisms, e.g., master/slaves or TDMA; • flexibility, as only pre-planned cyclic communications are enabled, and require an efficient synchronization protocol; • robustness management, because of the centralized fault management, classically provided by the master or network manager, which is considered as a central point of failure.

Hence, the main contribution of this work is the specifications of a new RTE protocol, AeroRing, which bridges the gap between existing RTE solutions, supporting ring topology, to enhance the resource utilization efficiency, the system flexibility and robustness management; in addition to guaranteeing the key requirements of safety-critical domains, such as avionics.

In the next section, we review the most relevant RTE solutions supporting ring topology and relate them to our proposal. Afterwards, the main innovative features of AeroRing, and its basic functionalities including the QoS and robustness management, are detailed in Sections 3 and 4, respectively. Finally, in Section 5, some numerical results on performance and reliability indicators of such a proposal are presented, to highlight its ability vs avionics requirements.

II. RELATED WORK

During the last two decades, a wide range of RTE solutions have been proposed by industrials and academia. The most relevant ones have been cited in the document IEC 61784-2 [START_REF]Digital data communications for measurement and control -Part 2: Additional profiles for ISO/IEC 8802-3 based communication networks in real-time applications[END_REF], which in addition introduces a set of Performance Indicators (PIs) to evaluate the RTE networks abilities. In this section, we first describe the most effective PIs and the main requirements to fulfill for safety-critical applications. Then, based on these requirements, we conduct a benchmarking of AeroRing and the most relevant IEC profiles supporting ring • Maximum Delivery Time, indicating "the time needed to convey an APDU containing data (message payload) that has to be delivered in real-time from one node (source) to another node (destination)" when considering the worstcase scenario. • Fault Detection Time, indicating the maximum time needed to all nodes to be aware of failure. • Redundancy recovery time, indicating "the maximum time from failure to become fully operational again in case of a single permanent failure".

Furthermore, we consider an additional PI, which is the maximum backlog to evaluate the memory utilization within network components. Numerical results concerning these aforementioned PIs of AeroRing are illustrated in Section V.

In addition to these PIs, RTE networks must fulfill a set of key requirements, which reveal particularly effective for many safety-critical applications, and particularly for avionics. These requirements concern both technical and costs aspects. The technical requirements are mainly the timeliness and the accuracy of delivered data, in addition to the reliability and availability of the communication network. Furthermore, the choice of the RTE solution shall be efficient to meet the design requirements for the least amount of money. Therefore, the IEEE802.3 compatibility, a minimized configuration effort and reduced implementation costs are among the most important issues to guarantee. These requirements will be considered to benchmark AeroRing against the most relevant IEC profiles, supporting ring topology and cited in IEC 61784-2 [START_REF]Digital data communications for measurement and control -Part 2: Additional profiles for ISO/IEC 8802-3 based communication networks in real-time applications[END_REF].

B. Benchmarking Most Relevant IEC profiles

Among the RTE solutions in [START_REF]Digital data communications for measurement and control -Part 2: Additional profiles for ISO/IEC 8802-3 based communication networks in real-time applications[END_REF], there is a first class with an implementation at the network layer, e.g., P-NET, V-NET, Modbus-RTPS and Ethernet/IP. These solutions are usually easier to implement and configure, but they lead at the same time to important latencies (about 10ms), which makes them more effective for soft real-time applications. Then, there is a second category providing a realization on top of the MAC layer while keeping the IEEE802.3 compatibility, e.g., TCNET, Ethernet/IP with Device Level Ring (DLR) and PowerLink, or modifying the standard implementation, e.g., EtherCAT and Profinet IRT. In this paper, we focus only on the most relevant RTE solutions supporting ring topology, and particularly EtherCAT, Profinet IRT and Ethernet/IP with DLR.

EtherCAT is defined by Beckhoff GmbH and supported by the EtherCAT Technology Group (ETG). It implements a master/ slave mechanism on top of Fast Ethernet (100Mbps). The main particularity of EtherCAT is the on-the-fly forwarding technique, which allows the slaves to insert the data requested by the master directly in the frame crossing couplers step by step. The EtherCAT frame is transmitted from the first slave to the last, and then back in the opposite direction to the master. This protocol provides interesting real-time performances due to the on-the-fly mechanism.

However, the main drawbacks of this technology consist of:

• the specificity of the EtherCAT devices, which increases the implementation costs and the configuration efforts;

• a central point of failure (i.e. the master) decreasing the reliability level.

PROFINET IRT (Isochronous Real-Time) is an extended version of PROFINET, which supports real time communications. It is a master/ slave network, based on cyclic communication handling two communication channels: isochronous and asynchronous. These latter are used by slaves to transmit real-time and non real-time data, respectively. The data is relayed using "Cut-through" to reduce the processing time. These functionalities require specific equipments and an accurate synchronization protocol. This protocol has similar pros and cons than EtherCAT due to its incompatibility with IEEE 802.3 and its master/slave mechanism.

Device Level Ring (DLR) protocol was introduced in 2008 by OADV organization to support hard real-time communication with Ethernet/IP. DLR is based on a ring controller, called active ring supervisor, which collects data from the other interconnected nodes on only one port to avoid infinite traffic loop, except some specific frames, i.e., beacons. Each equipment has two Ethernet interfaces and an integrated switch, which implements Store & Forward mechanism and Static Priority service policy. Moreover, fault detection and reconfiguration mechanisms are handled within the controller via specific messages, i.e., beacon and announce. This protocol has interesting features in terms of reliability due to the fault detection mechanism within the controller, and reduced costs due to standard devices. However, the non-nominal case needs the reconfiguration of the supervisor, which increases the configuration effort. Furthermore, integrated switches based on Store & Forward mechanism induce high transmission latencies, which decrease the offered real-time performance and availability levels.

The benchmarking of these RTE solutions vs the main identified requirements in Section II-A is illustrated in Table I. EtherCAT and Profinet IRT imply higher costs due to the specificity of the implemented devices, and lower reliability due to the master/slaves mechanism (i.e. inducing a central point of failure), than Ethernet/IP with DLR. This latter is based on standard devices and implements fault detection and reconfiguration mechanisms, which enhance costs and reliability. Concerning real-time performance, EtherCAT and Profinet IRT allow very short latencies due to on-the-fly and Cut Through mechanisms, whereas Ethernet/IP with DLR induces high latencies because of the Store & forward one. Moreover, these transmission latencies have a direct effect on the fault detection time, and consequently the availability level. Hence, the offered real-time performance and availability levels of EtherCAT and Profinet IRT are higher than Ethernet/IP. It is worth noting that each RTE solution satisfies selected requirements better than others, but there is no best solution in terms of all the requirements.

Our objective is to specify a new RTE solution, AeroRing, which bridges the gap between these aforementioned RTE solutions, to guarantee the high reliability level of Ethernet/IP with DLR and the high real-time performance and availability levels of EtherCAT and Profinet IRT. Moreover, this new RTE solution has to keep the IEEE802.3 compatibility and reduce the implementation costs and configuration efforts. Hence, the AeroRing abilities vs the the main identified requirements are illustrated in Table I.

The main innovative features of AeroRing are as following:

• Distributed access mechanism, allowing simultaneous data exchange to increase the offered bandwidth and resource usage efficiency; Table II illustrates a summary of the main characteristics of AeroRing and the aforementioned RTE solutions, and particularly the pros and cons of each solution.

III. WHAT IS AERORING

In this section, we present the main fundamental concepts of AeroRing network, including T-AeroRing features and data processing.

A. T-AeroRing Features

As illustrated in Fig. 1, AeroRing network implements a daisy-chain wiring scheme on top of a Full Duplex ring topology. It allows any "Ethernet-compliant" equipment to transmit its data via a specific end-system, named T-AeroRing. Each transmitted packet will be forwarded from one T-AeroRing to another until reaching the final destination, and some particular cases will be detailed in the next section.

The T-AeroRing is a specific 3 ports Full Duplex Ethernet switch having the internal architecture illustrated in Figure 2, and the following main characteristics:

• Cut-Through forwarding technique: the T-AeroRing starts forwarding the packet just after its identification, i.e. only the header of each packet is decoded to determine its destination port. This technique guarantees shorter transmission latency than the "Store and Forward" technique (implemented within Ethernet/IP), which waits until the complete reception of the packet before forwarding it to the destination port;

• Static Priority service policy packets are queued in each output port of T-AeroRing according to their priorities. A queue is selected for transmission only if all traffic classes queues with higher priorities are empty. Then, for each queue, the scheduling order is First In First Out (FIFO) with a non-preemptive transmission. Priority is defined according to the IEEE 802.1p standard where the 802.1Q tag (3-bits field) is used to manipulate the four priority classes;

• Traffic policing: To guarantee real-time performance, the T-AeroRing implements traffic policing mechanisms, based on Leaky Bucket method and particularly greedy method [START_REF] Wandeler | On the Use of Greedy Shapers in Real-Time Embedded Systems[END_REF], to control each traffic class compliance with its predefined contract to avoid the network saturation. These traffic contracts are defined based on the network designer specifications. Each equipment connected to a T-AeroRing should be aware of these traffic contracts, and may apply traffic shaping to ensure the conformity of its generated traffic and avoid being discarded by the traffic policers. Each traffic exceeding its associated contract may be discarded to guarantee the communication determinism;

• QoS-aware routing: unlike COTS Ethernet switches which relay frames on the basis of the address learning process and the Spanning Tree Algorithm, each T-AeroRing builds its routing table on the basis of the network management messages, exchanged between the interconnected T-AeroRings during the initialization phase or when a topology modification occurs (i.e. failure or restoration). Each T-AeroRing implements two routing modes to transmit its generated packets depending on their priorities: (i) sending on both ring ports (Ports 1 and 2 in Fig. 2) for high priority traffic classes, i.e., network management and HRT data, to allow a high reliability level ; (ii) sending on the port corresponding to the shortest path for medium and low priority traffic classes, i.e., SRT and NRT data, to offer a high performance level (i.e. short delay);

• Frame Redundancy Management: Like AFDX end-systems, the T-AeroRing implements a Frame redundancy management mechanism to detect redundant frames generated by the first routing mode, and to determine whether to deliver the packet to the final destination or drop it because its replica has already been received. In practice, all packets sent on both ring ports are provided with a 2-bytes sequence number field that occurs just before the FCS field, which will be checked at the destination;

B. Data processing

Based on the description of T-AeroRing ports in Fig. 2, each frame will be processed as follows in the nominal case:

• Any frame received on a network port (1 or 2) is relayed to the other port unless the frame is destined to the connected equipment, or this latter is the frame source. • Any frame received on a network port (1 or 2) destined to the connected equipment is delivered to it, according to the redundancy management mechanisms. • Any frame received from the connected equipment is transmitted on one or both network ports depending on its priority: the highest priority traffic class is tagged by a 2-bytes sequence number and transmitted on both ports, while the medium and lowest priorities traffic classes are transmitted on the port corresponding to the shortest path.

IV. NETWORK FUNCTIONALITIES

In this section, we present the main functionalities of AeroRing, including the QoS and robustness management and the auto-configuration mechanisms.

A. Real-Time behavior and QoS Management

The real-time behavior of AeroRing and the timeliness guarantee of the delivered data are favored due to the implemented features within the T-AeroRing. First, the "Cut Through" forwarding technique allows a short transmission time along the network, which improves the Maximum endto-end delivery time. Then, the traffic policing mechanism prevents a network saturation by a deficient equipment, which guarantees the communication determinism. Furthermore, the implemented QoS-aware routing algorithm supports the transmission of the SRT and NRT data on the shortest path, which decreases their transmission delays. Finally, the Static Priority policy ensures the temporal isolation between mixed criticality data with various temporal constraints, and guarantees a bounded delay for the HRT traffic class.

On the other hand, AeroRing guarantees QoS management through the implementation of "Static Priority" policy, which supports the following traffic classes:

1) Control Messages: This traffic class has the highest priority level (N0) and is used for network management issues, such as: (i) building the routing tables of the interconnected T-AeroRings; (ii) the fault detection management; (iii) neighbor status checking. For the two former, the control messages are sent on both ring ports to ensure a high reliability level; whereas for the latter, the control messages are only sent to the neighbors, if no data to send, to check their status and guarantee a fast fault detection;

2) HRT Messages: this traffic class has the second highest priority level (N1) and is assigned to real-time applications with hard temporal constraints, i.e. the message must be received before its deadline otherwise it is considered lost. This type of messages is sent on both ring ports to ensure a high reliability level, and is identified by a 2-bytes sequence number, essential for the frame redundancy mechanism within the destination T-AeroRing;

3) SRT Messages: this traffic class has the medium priority level (N2) and is assigned to soft real-time applications, such as audio or video transfers. This type of messages is sent on the ring port corresponding to the shortest path to guarantee a high performance level, i.e. short transmission delay; 4) NRT Messages: this traffic class has the lowest priority level (N3) and is assigned to non real-time applications, such as file transfer. This type of messages is sent on the ring port corresponding to the shortest path to guarantee a high performance level;

It is worth noting that the AeroRing is compatible with the IEEE 802.3 standard and each T-AeroRing can deliver any type of "802.1x-compliant" frame from the equipment. Hence, if the frame does not include the 802.1Q tag, then it will be treated as a NRT data frame (N3), and transmitted on the ring port corresponding to the shortest path.

B. Auto-Configuration Mechanism

To reduce the configuration effort for the network designer and facilitate this new RTE solution adoption in the market, AeroRing offers an auto-configuration service until all the T-AeroRings become operational. This service is based on a simple address assignment method and a dynamic network topology discovery process. The address assignment of the connected T-AeroRings method consists in assigning the equipment MAC address to its corresponding T-AeroRing, when it joins the network. This fact facilitates the communication between the connected equipments and avoids a heavy translation addresses step.

At the beginning, each T-AeroRing which is not connected to an equipment, has a default address MAC. Then, each freshly connected T-AeroRing enters a network topology discovery phase and behaves as follows:

• transmit periodically control messages on each ring port until receiving a control message from another T-AeroRing on the same port. This means that it has a neighbor on that side and it is no longer the last node of the segment. This period can be tuned according to the application requirements by the network designer. • stop transmitting control messages when detecting both neighbors. Hence, the control messages transmission stops when the ring loop is closed.

Furthermore, on the basis of these control messages exchanged between T-AeroRings, each T-AeroRing builds a routing table per port. These routing tables allow to select the port corresponding to the shortest path (ports 1 or 2) for a destination. Each exchanged control message contains the list of MAC addresses of the crossed T-AeroRings, according to their physical positions along the network.

Figure 3 shows the structure of a control message. The control messages are identified by the value type of "0x9000". Then, the CTL field identifies the type of the control message, where "0001" is reserved to build the routing tables, and NBAD field is a counter of the MAC addresses, which are inserted in the ADDx fields.

Type Payload 0x9000 CTL NBAD ADD1 ADD2 ADDN-1 ADDN ..... (2) (4 bits) (12 bits) (8) (8) (8) (8) (8)
Fig. 3. Structure of a control message These control messages to build the routing tables are managed as following:

• at each topology change, i.e. start, failure or restoration, the T-AeroRings detecting this event send a control message on both network ports in broadcast mode with the highest priority, to update the routing tables of the other interconnected T-AeroRings; • each T-AeroRing contributes in building the routing tables: when receiving the control message, it inserts its MAC address at the end of the list to respect the physical order, increment the NBAD counter, forwards it to the next T-AeroRing and updates its routing table (i.e. inserts MAC addresses of new equipments and deletes the ones that no longer exist) (see the example in Fig. 4).

C. Robustness Management

AeroRing offers a high reliability and availability levels due to its implemented features. First, redundancy management mechanisms are defined for both network and frames. Then, error detection and recovery mechanisms are implemented. Finally, a distributed fault detection and reconfiguration management is supported, which avoids single point of failure.

1) Redundancy Management:

AeroRing supports redundant topology where each equipment may be connected to redundant T-AeroRings and transmit its data on two redundant networks (see Fig. 5). These redundant networks might be used in a complementary way, i.e., the packet is sent only on the main network in the nominal case and on the backup one in case of failure; or in a symmetric way, i.e., each packet is replicated and sent on both networks. Each equipment implements a redundancy management mechanisms to identify packets (replicas) that arrive on both networks to consume the packet or drop it because its replica has already been received. Furthermore, according to the QoS-aware routing algorithm within the T-AeroRing, the HRT traffic is sent on both ring ports to enhance the availability and reliability level. Each T-AeroRing implements a Frame redundancy management to detect redundant frames to determine whether to deliver the packet or drop it. 2) Error Detection and Recovery Mechanisms: Similar to standard Ethernet solution, AeroRing supports the error detection through the FCS field to discard erroneous frames. However, if the error is not detected based on the FCS field, and it occurs on the header, then the frame has to be eliminated from the network to avoid infinite packet looping. Each T-AeroRing implements a filtering function to prevent this phenomena. A frame with an erroneous destination address will be filtered by its source. However, if the source address is incorrect, any T-AeroRing can eliminate the erroneous frame when detecting that the erroneous address does not exist in its routing table.

3) Fault Detection and Reconfiguration Mechanisms:

Any T-AeroRing has to consider a connection as down with a neighbor, if it does not receive any message from its neighbor during a certain period called "detection period". This detection period can be easily tuned by the network designer. In practice, if a T-AeroRing has no data to transmit to its neighbor, then it announces periodically its status to that neighbor through sending control messages. These latter have the CTL field set to "0000", and empty NBAD and ADDx fields (see Fig. 3).

These control messages to announce the status to neighbors are sent periodically when at least one of the following conditions is satisfied:

• The T-AeroRing does not have any data to send on this port during a period called "announcing period" (this period is less then the detection period that covers in general the reception of more than one control message); • The T-AeroRing did not receive any data or control message from this port for a duration equal to the detection period. In this case, the T-AeroRing indicates to its neighbor through a control message that the connection is considered as down.

When a connection is considered as down by one of the interconnected T-AeroRing, this latter sends a first control message to inform the other T-AeroRings with the CTL code "0010", followed by a second control message to update the routing tables (see the example in Fig. 6). A down connection is considered operational again (up), if the T-AeroRing starts receiving frames (data or control) from its neighbor. In this case, it sends a control message to update the routing tables of the other nodes.

It is worth noting the existence of various redundancy protocols for RTE solutions with ring topology, and the most relevant ones in our case are the Distributed Redundancy Protocol (DRP) [START_REF]Industrial communication networks -High availability automation networks -Part 6: Distributed Redundancy Protocol (DRP)[END_REF] and the Ring-based Redundancy Protocol (RRP) [START_REF]Industrial communication networks -High availability automation networks -Part 7: Ring-based Redundancy Protocol (RRP)[END_REF].

The DRP implements similar local fault detection mechanisms than AeroRing, where each equipment can check the status of its neighbors by sending a link test frame LinkCheck to detect failures. However, unlike AeroRing, in addition to these local mechanisms, DRP implements a centralized fault detection mechanism to check the ring status in a cyclic manner, i.e., during each cycle, only one equipment can check the ring status via a ring test frame RingCheck, gather and broadcast the information to the rest of equipments. Furthermore, an accurate synchronization protocol is required to manage such a cyclic process.

On the other hand, the RRP implements similar distributed mechanisms than AeroRing to build the routing tables within equipments. However, unlike AeroRing, RRP consists in transforming the ring topology into line topology to avoid infinite packet looping, through selecting two adjacent devices, called Ring Network Managers (RNMs), which disable one of their ports. This choice will clearly deteriorate the reliability level, compared to AeroRing, since sending on both directions becomes forbidden. Moreover, RRP implies higher communication overhead to build the routing tables than AeroRing, i.e., there are as many exchanged messages as equipments to update the routing tables under RRP, whereas only one control message is necessary with AeroRing.

Hence, unlike DRP, AeroRing implements a completely distributed redundancy protocol, based only on local fault detection mechanisms and without any need of synchronization protocol. Furthermore, unlike RRP, the T-AeroRings build autonomously their routing tables with a low induced overhead, and messages can be sent on both directions or only on the shortest path, according to the message class.

V. PERFORMANCE AND RELIABILITY ANALYSIS

In this section, we investigate the offered performance and reliability levels of AeroRing through a representative case study. Therefore, we give first numerical results on some specified PIs, such as the upper bounds on the end-to-end latencies and backlogs, and the maximum detection and recovery times. The detailed analyses of these PIs are beyond the scope of this paper.

A. Case study

We consider the following assumptions:

• The links speed is C = 1Gbit/s; • The network size varies from 4 to 40 nodes (40 is the medium size specified in the IEC document [START_REF]Industrial communication networks -High availability automation networks -Part 1: General concepts and calculation methods[END_REF] to benchmark RTE solutions); • All equipments are similar and send the same traffic in broadcast mode; • Technological latency within the T-AeroRing is 600ns;

• Each equipment generates 3 types of traffic classes (TC) as described in Table III; • The "detection period" for fault management is 0.5ms.

It is worth noting that in the broadcast mode, the notion of "shortest path" does not exist for the traffic SRT and NRT. In this case study, we consider that all the SRT and NRT messages are sent on the same direction, which corresponds to the worst-case scenario in terms of performance, i.e., this choice increases contention.

B. Numerical Results

Figures 7 and 8 illustrate the upper bounds on the endto-end latencies and backlogs, respectively. Obviously, these metrics increase with the network size, since the number of generated messages and crossed nodes increases.

As we can notice, for a network of 40 nodes, the upper bound on the end-to-end latency for the highest priority is less than 2ms, and the maximum backlog is less than 300Kbit.

Figures 9 and 10 illustrate the maximum detection and redundancy recovery times. These metrics depends on the length of the control message updating the routing tables, which increases with the number of crossed nodes. For a network of 40 nodes, the maximum detection and recovery times are less than 0.75ms and 1ms, respectively.

VI. CONCLUSION AND FUTURE WORK

A new RTE solution, called AeroRing, has been proposed in this paper to handle the emerging requirements of new generation aircraft in terms of decreasing the wire complexity and integration costs, and enhancing the real-time performance and availability. This solution has many advantages, compared to the most relevant RTE solutions supporting ring topology, such as:

• enhancing the performance and the resource usage efficiency due to its distributed access mechanism and its QoS-aware routing algorithm; • offering high availability and reliability levels through a distributed fault management mechanisms, which avoid any single point of failure; • improving the network flexibility through event-triggered communication support without any need of synchronization; • minimizing the implementation costs due to its compatibility with IEEE 802.3 standard, and the configuration effort through its auto-configuration mechanisms.

AeroRing has been specified to fulfill the avionics requirements, but it can be easily extended for other industrial application fields, such as automation and control. This adaptation will be investigated as a next step of our work. Furthermore, AeroRing consortium is working on the standardization process of such a proposal with open source specifications, to facilitate its adoption in the market.

Fig. 1 .

 1 Fig. 1. AeroRing network

Fig. 2 .

 2 Fig. 2. T-AeroRing internal architecture

Fig. 4 .

 4 Fig. 4. Example of routing table building

Fig. 5 .

 5 Fig. 5. Example of an AeroRing redundant topology

Fig. 6 .

 6 Fig. 6. Fault detection Mechanism

Fig. 7 .

 7 Fig. 7. Upper bounds on the end-to-end latencies vs number of nodes

Fig. 10 .

 10 Fig. 10. Maximum recovery time vs number of nodes

  • Distributed fault management mechanism, avoiding the central point of failure to provide high Reliability and Availability levels;

• Event-triggered communication, enhancing the system flexibility and decreasing the implementation complexity, through avoiding any need of synchronization; • QoS management, handling heterogeneous data constraints. This feature is guaranteed through the implementation of a Static Priority (SP) policy supporting four traffic classes: the network management class with the highest priority, the Hard Real Time (HRT) with the second highest priority, the Soft Real Time (SRT) class with medium priority and finally the Non Real Time (NRT) class with the lowest priority. • QoS-aware routing algorithm, sending HRT on both ports to improve reliability, and the SRT and NRT traffic classes on the shortest path to enhance resource usage efficiency; • Compatibility with IEEE802.3, guaranteeing an easy deployment process and a cost-effective integration.

  To avoid infinite packet looping as a result of broadcast communication or erroneous header information, each T-AeroRing implements a filtering function which consists in: (i) eliminating all its generated packets sent on one port and received on the other port. This case occurs for broadcast packets or those with erroneous destination address; (ii) eliminating all received packets with erroneous source address. This verification is possible due to the cut-through technique and the routing table, i.e. an erroneous address does not exist in the routing table.

• Filtering Function:

Aeroring is co-funded by the European Union. Europe is involved in Midi-Pyrenees through the European Funds for Regional Development.


Applying MILS principles to design connected embedded devices supporting the cloud, multi-tenancy and App Stores

Applying MILS principles to design connected embedded devices supporting the cloud, multi-tenancy and App Stores

Embedded, connected devices are nothing new. Developers have been establishing Machine to Machine communications for 20 or 30 years, long before the Internet of Things was ever conceived.

But until quite recently, embedded applications have tended to be static, fixed function, device specific implementations. In the current environment of ever quickening technological change, morphism and evolution are the order of the day. Now we see manufacturers and service providers all seeking to monitor, upgrade, enhance and supplement software implementation on a continuous basis.

In the enterprise world, cloud computing and "X"-as-a-service (PaaS, IaaS, SaaS) architectures have dramatically changed the economics of IT such that the infrastructure is now a utility or service rather than a capital investment. This has enabled significant innovations in service, including App Storeslibraries of products and services that are supported by the infrastructure and provide single instances of cloud-based software for the benefit of multiple "tenants".

In the IoT, embedded devices are somehow connected to the "cloud". However, the benefits of the IoT are unlikely to be realized unless the connected embedded devices are capable of supporting the multi-tenanted architectures that are common in enterprise IT. This implies that IoT devices need to provide secure separation between the different tenants accessing the IoT infrastructure.

For example, imagine a car as an IoT gateway device, with many demands on its systems infrastructure. Of course, the manufacturer will be first in the queue, providing software updates to security critical aspects of the vehicle and monitoring its condition. But alongside this core functionality there will also be a host of Apps from the Store to enable and entertain. The navigation service provider, accessing continuously evolving road data. Insurance applications, monitoring probationary drivers to help minimize premiums. Media streamers with the latest movies. Games, advertisements, and a host of other possibilities as yet unrealized.

Multi-tenancy without security is not enough. As if to highlight that point, at the 2010 IEEE Symposium of Security and Privacy, researchers from the University of Washington and the University of California -San Diego remotely accessed the systems on a late model car to unlock the doors, start and stop the engine, lock brakes and disable windscreen wipersall potentially life threatening actions1 .

In their paper on the subject, the researchers observed that "While the automotive industry has always considered safety a critical engineering concern (indeed, much of this new software has been introduced specifically to increase safety, e.g., Anti-lock Brake Systems) it is not clear whether vehicle manufacturers have anticipated in their designs the possibility of an adversary. Indeed, it seems likely that this increasing degree of computerized control also brings with it a corresponding array of potential threats. Compounding this issue, the attack surface for modern automobiles is growing swiftly as more sophisticated services and communications features are incorporated into vehicles."

It is precisely these conflicting demands for security and accessibility which makes this and similar environments quite so challenging.

Designing an IoT Gateway

Generalizing the automotive example to the wider Internet of Things, it is useful to consider exactly what properties are desirable in an IoT Gateway. Traditional embedded designs using COTS embedded operating systems can present many compromises.

Traditional embedded gateway designs rely on monolithic architectures, such that applications are hosted by a single operating system and all I/O support, management controls, and security controls are integrated into the operating system kernel. This monolithic construction creates the following challenges:

 Fragile Single Point of Failure IoT gateways are highly susceptible to attacks and failure due to their wide exposure to the internet across so many interfaces supporting a great deal of complex functionality. Because monolithic designs host all applications, perform I/O, and management functions, any failure in security policy or kernel coding flaw can jeopardize the security and availability of the system which will greatly limit the ability to operate in stringent safety markets.

 Weak Separation

In order to provide a platform as a service a strong degree of separation will be needed to prevent collocated applications from compromising the privacy or availability of other applications. Relying on a monolithic operating system to provide separating computing environments is risky given the number of ways monolithic operating systems can fail or be subverted.

 Limited I/O Support

With a monolithic design, all sensor and network interfaces drivers and I/O stack support must be built into the operating system kernel. If drivers do not exist for the selected OS, it can be difficult to support all varieties of desired sensor support and network interfaces.

 Limited Application Support

Certain applications may only be available for certain operating systems. Choosing an OS that provides the best IO support, application support, ideal deterministic behaviour, and secure design may not be feasible.

 Limited Online Maintenance

Due to highly complicated interdependencies of functionality in monolithic operating systems, the ability to patch or upgrade kernel functionality while maintaining platform operation is highly limited. The majority of kernel maintenance procedures require platform reboots which pose significant challenges for platforms that strive for full autonomy.

The majority of issues in relying on a monolithic operating system as the foundation of an IoT gateway stem from limited application and IO support, and exposure to a single point of failure. A better approach is to have a more modular design that can provide more interoperability options and achieve higher levels of reliability and assurance.

Given these traditional designs are compromised, it is useful to consider relevant academic principles as a basis for a better solution.

The application of MILS principles

The solution to this conundrum lies in the MILS (Multiple Independent Levels of Security/Safety) initiative. MILS is a high-assurance security architecture based on the concepts of separation and controlled information flow; implemented by separation mechanisms that support both untrusted and trustworthy components; ensuring that the total security solution is non-bypassable, evaluatable, always invoked and tamperproof 2 . A MILS compliant distributed secure system for the connected car will therefore comprise of high-assurance components and applications which can be independently developed, modularly combined, evaluated and certified to adhere to these principles, in all aspects of its development.

This paper outlines the principles and application techniques surrounding three enabling technologies.

1. Least Privilege Separation Kernel Hypervisor, 2. MILS based network components for network traffic encryption and the consolidation of multiple encryption tunnels 3. MILS based data handling components to encrypt data and consolidate multiple storage partitions

Least Privilege Separation Kernel

The foundation of any such MILS compliant system is the Separation Kernel, a concept first mooted in 1981 by John Rushby3 . A separation kernel consists of "a combination of hardware and software that permits multiple functions to be realized on a common set of physical resources without unwanted interference". By implication that suggests that the only interaction between the "security blocks" is by design, and that primary information flow will be from high to low security blocks (Figure 1).

Figure 1. Primary information flow is from high to low security blocksbut some flow is required in the opposite direction.

A few years earlier in 1975, Saltzer and Schroeder4 established a similar set of principles based on the idea of modularization, noting that "Every program and every user of the [operating] system should operate using the least set of privileges necessary to complete the job". The concept of a separation kernel clearly goes some way towards that goal, but because separation kernels are traditionally based on resource isolation there was insufficient granularity to take that principle to its conclusion.

That coarse granularity, coupled with an inevitable requirement for at least some flow of information from low to high security blocks, results in considerable emphasis being placed on developers if the boundaries are not to be breached.

The idea of marrying the two was therefore proposed by Levin, Irvine and Nguyen5 resulting in the concept of a Least Privilege Separation Kernel, where both resources and subjects (executable entities) could be modularized. In this way, no subject needs to be given more access than required to allow the desired flows (Figure 2).

Figure 2. Superimposing Least Privilege principles on to those of a Separation Kernel combines persubject and per-resource flow control granularity

In practical terms, the modularity of this approach enables the creation of de-privileged configuration utilities, device drivers, guest virtualization, device virtualization and management services.

Hypervisor functionality is almost a by-product of this architecture, in that the subjects illustrated in Figure 2 can consist of anything from a minimally sized, "bare metal" application to a fully featured Real Time or General Purpose Operating System.

MILS based network and data storage components

In the context of our automotive example, this Least Privilege Separation Kernel Hypervisor may well be a well-founded principle, but it is only useful if it can be applied to provide the secure environment we need to ensure that the car as an "IoT gateway device" is not vulnerable to the attacks of the troublesome researchers and others with more malicious intent.

This has to be achieved, however, in the context of an existing infrastructure consisting very largely of the public internet. The onus for security therefore falls on the gateway devicesand in our case, that means the systems contained within the car.

There are also cost considerations to consider, particularly in the case of the ever expanding functionality of the modern car. To that end, it is important that the high build and maintenance costs associated with multiple vehicle networks should be avoided. Figure 3 shows how such a system could be designed in practice. The networking and data handling are implemented as minimalist least privilege "subjects", tightly coded and running as "bare metal" applications to minimize their footprint and hence vulnerability.

The configuration of the system is completed statically at installation time, and the facilities for modifying that configuration do not exist once the system is running.

Three virtual machine (VM) subjects provide the means to run the Apps, possibly mapped to the individual cores of a multicore processor where there is hard real time dependency.

Encryption keys ensure the integrity of three tiers of data security, while the Least Privilege Separation Kernel provides the underpinnings to guarantee that the trusted code base underpinning the system is minimalized.

The net result is a robust solution, providing resilient application interfaces to prevent malicious software from subverting the virtual software architecture. It ensures the integrity of critical applications by protecting them from possible corruption from other application partitions. Costs are minimized and yet confidentiality is guaranteed through the application of a single network structure. And it can be ensured that vehicle applications are genuine, and that network encryption cannot be bypassed by server vehicle application VMs.

In summary, by applying the MILS principles throughout, the security/accessibility conundrum is resolved.

solutions greatly exceed the levels of reliability compared to a solution running on a monolithic operating system.

Least Privilege Separation Kernel Hypervisor under attack

All of these features clearly have merit, but ultimately the Separation Kernel Hypervisor itself is the critical component of the architecture; the trusted code base that makes the rest of the architecture possible. That make it a primary target for attack.

It would be bold or foolish to claim that it could never be compromised, but the theoretical principles which guided its design also highlight why that threat is optimally defended.

All attacks require an attack vector; a means of entry, commonly a NIC or device driver. LynxSecure offers no such direct attack vector because in accordance with the principles of a least privilege separation kernel, device drivers and communication mechanisms such as NICs are all placed within VMs.

The possible configuration permutations of LynxSecure are almost countless. The superimposition of Least Privilege principles on Separation Kernel blocks results in fine per-subject and per-resource flow-control granularity, and so communication paths only exist if the system architect wants them.

Where they must exist, should there be a concern that communication between VMs by means of a virtual Ethernet and its well-known protocol, then the architect might prefer to take advantages of the proprietary "hypercalls" API which adds an element of "security by obscurity" to the design.

Figure 3 shows an example of a communications mechanism between VMs by means of virtual network cards. That clearly involves communicating through LynxSecure, but not with it. In other words, for this to represent a vulnerability there would have to be coding deficiencies to compromise the integrityand the very fact that it is so small and has been certified to very high standards means that the risk is tiny.

Finally, LynxSecure is statically configured. The mechanism required to modify that configuration does not exist at run time, and so there is no possibility of the installed configuration being modified by an attacker.

In summary; there has to be a communications path through the gateway for it to fulfil its purpose, and that implies the existence of possible means of compromise. But here, the risks are kept to an absolute minimum in accordance with the principles on which its design is founded.

Least Privilege Separation Kernel Hypervisor in practice

The example of an automotive application is highly topical (figure 4). It is perhaps no surprise that it is presently under review by a number of vehicle manufacturers and their tier one suppliers, and that at the time of writing the commercial relationships involved mean that detailing their practical application here is not possible.

The security issue highlighted is new to the automotive sector, because until recently cars have been secure simply by virtue of being isolated. However, that is not true of all other fields of endeavour, and there are practical applications of this technology dating back for almost a decade. This state of affairs therefore has the potential to offer the automotive and other sectors a proven and seasoned solution to a new and challenging problem.

One field where security has always been paramount in in the military, and it is perhaps natural that Separation Kernel Hypervisors have therefore found many of their earliest practical applications in that field. Such applications clearly demand certification in accordance with military security standards. For example, a US armed forces program has used a Separation Kernel Hypervisor as the security foundation for an embedded mission critical security solution. This solution successfully underwent a security certification involving extensive penetration and other testing for use in DOD High Threat Environments, satisfying the following security requirements:

 Director of Central Intelligence Directive (DCID) 6/3 Protection Level (PL) 4separation of Secret to Secret/compartmented security domains in the presence of untrusted users.

 8500.2 Mission Assurance Category I (MAC I) for systems handling information that is determined to be vital to the operational readiness or mission effectiveness of deployed and contingency forces in terms of both information system content integrity and timeliness/availability. Although further details about this certification and others like it are classified, the artefacts created to achieve that certification are mostly generic and hence relevant to other certification processes.

Other "real life" applications include  A UAV ground controller, providing a user interface and control platform for controlling unmanned vehicles. The use of a Separation Kernel Hypervisor in this environment provided o A path to certification, o Safety critical partitioning of the user interface from the control function, o Deterministic control, and o Flexible application options.  An electronic "flight bag", consisting of a cockpit user interface for features including a map display an electronic forms. In this case, the Separation Kernel Hypervisor provided o The separation of a low integrity user interface from a high integrity aircraft bus o The optimal OS for each application, permitting the use of state-of-the-art graphics o A certifiable approach to isolating fully virtualised OS

Separation Kernel Hypervisor Based Design Strategies -an example

Suppose that there is a requirement for an IoT gateway in a traffic control application. In its simplest form, the gateway in the system is providing local control for a set of traffic lights. Road sensors provide information about what is happening to the traffic flow, the gateway provides local control to action the immediate policies, and the policy decisions are derived from the command centre based on the information fed back to it from the gateway.

Figure 5. A simple IoT Gateway application providing local control for a set of traffic lights (left). More complex traffic control requires local peer-to-peer communication as well as policy decisions downloaded from a command centre (right)

As this system is expanded, so the intercommunication between gateways and the command centre becomes more complex. Immediate traffic flow issues are management by means of local P2P networking while the policy decisions are still downloaded from the command centre (figure 5)

Figure 6. the system requires multiple domains to permit the various tenants safe access to the same TCP/IP stack Ultimately, the system requires third party access to collate data for traffic reporting; naturally a less critical domain requiring separation from the traffic control functionality of the system (figure 7).

In the context of this traffic control system, several attributes of the Separation Kernel Hypervisor based gateway are significant.

 Modular Composition

Using the virtualization and bare-metal application capabilities, and relying on the isolation and deterministic properties of a Separation Kernel Hypervisor, platforms can be constructed out of a variety of software modules where individual functions of the platform can run in independent partitions and simple interfaces between modules can be defined so that the state of the system is well defined and understood.

Modular designs promote better options for interoperability and sustainability. For example, gateway maintenance routines such as new sensor device or network interface upgrades or bug patches can be performed without powering down the device or disrupting vital operational components.

In the traffic control system (figure 7), we see a partition hosting a VM dedicated to the local lights and signage, a second to the receipt and analysis of data, and a third transmitting data to a traffic report service. An additional VM running a bare metal application ("Security abstraction") takes care of the encrypted data from the different tenants.

 Heterogeneous Computing

Relying on virtualization, architects can mix and match combinations of operating systems concurrently running on the same platform to host a wide variety of applications and I/O interfaces that may be exclusive to certain operating systems. Heterogeneous computing is an excellent strategy for supporting the most interoperable designs, and defending against proprietary vendor lock-in or obsolescence.

The traffic control example might deploy a bare metal application for the Network Gateway VM and the traffic signal control, perhaps an RTOS for the data analysis, and a general propose OS for the traffic report data handling.

 Fault Tolerance

Relying on the robust and highly available backbone of the Separation Kernel Hypervisor and modular design principles, system architects can create fault-tolerant designs using heart-beat and health inspection techniques. Some Separation Kernel Hypervisors allow guest operating systems to report their health status, policies can be set in a Separation Kernel Hypervisor to reboot or repair modules in the event of failed health status reports. Furthermore specialized custom modules can be created to inspect the health of other modules either through communication protocols or simply giving inspection modules access to view operating system and bare-metal application memory resources.

 Security Abstraction

A good architectural approach is to design systems such that applications run in separated environments from security sensitive applications to prevent security controls from being bypassed or infiltrated. In the traffic control system, the "Security Abstraction" layer takes the form of a VM running a bare metal application takes care of the encrypted data from the different tenants to prevent users from disabling or bypassing the crypto function.

Conclusions

Monolithic architectures pose significant challenges in the ability to support stringent safety standards and meeting demanding market needs. With the use of a Separation Kernel Hypervisor and modular design techniques, IoT gateway vendors are given many options for building highly interoperable, reliable, secure, and sustainable solutions using low cost COTS components.

The automotive industry in particular has suffered by moving from a world where system isolation offers the ultimate security protection, to the connected car where that past assumption makes it especially vulnerable.

Such industries cannot discard all existing code and applications, and re-write them overnight. Separation Kernel Hypervisors offers the proven, certified technology to provide separation of that vulnerable software from the dangers of external public access. This is not new technology. It is proven and has been certified and in use in the US military for almost a decade. It is not an operating system; not even a cut down operating system. It is a separation kernel, leveraging hardware virtualization to minimize both the trusted code base and the attack surface.

Figure 3 .

 3 Figure 3. Superimposing Least Privileged subjects to handle data storage and networking functionality on the Least Privilege Separation Kernel Hypervisor.

Figure 4 .

 4 Figure 4. The vulnerability of the connected car is a highly topical subject, and a thorny one for the automotive industry

Experimental Security Analysis of a Modern Automobile http://www.autosec.org/pubs/cars-oakland2010.pdf

https://en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security

Design and Verification of Secure Systems. John Rushby, Computer Science Laboratory, SRI International. 1981.

Saltzer and Schroeder, The Protection of Information in Computer Systems, ACM Symposium on Operating System Principles(October 1973)

T. E. Levin, C. E. Irvine, and T. D. Nguyen. Least privilege in separation kernels. In J. Filipe and M. S.Obaidat, editors, E-business and Telecommunication Networks; Third International Conference, ICETE

The Gateway based on the Least Privilege Separation Kernel Hypervisor

It is useful to summarize the pertinent capabilities and properties offered by Least Privilege Separation Kernel Hypervisors (more succinctly, "Separation Kernel Hypervisors") in the context of the design of IoT gateways in general, and by implication, the connected car in particular.

 Virtualization

Separation Kernel Hypervisors offer the ability to run multiple variants of guest operating systems concurrently on the same platform. This capability provides many options for hosting applications from multiple different operating systems and supporting a variety of different sensor devices and network interfaces. For example, through virtualization a design can be made where timing critical applications such as load-balancing and failover protocols run in real-time operating systems while running lessor critical applications in more feature rich operating systems. Virtualization is a key capability in dealing with interoperability challenges. Virtualization also plays a key role in supporting edge computing and platforms as a service, allowing analysis tools and tenants to use any operating systems and application best suited for the target task.

 Bare-metal Applications Some Separation Kernel Hypervisors provide the ability to run applications without the assistance of an operating system. Bare-metal applications are helpful for designs that require high performance or high assurance. Removing the dependency of an operating system reduces application overhead. For deployments that face stringent safety and security requirements, code reviews of critical applications may be necessary. Bare-metal applications can greatly aid the code analysis process by removing the complex code dependencies on the operating system.

 Full Mediation

Separation Kernel Hypervisors provides the ability to explicitly monitor and control all platform transactions. This allows system architects to gain full awareness of the state of the system that can be used to help improve platform availability and assurance.

 Isolation

Separation Kernel Hypervisors partition hardware resources and assign them to either Guest OSs or bare-metal applications according to a specification defined by a system architect. Separation Kernel Hypervisors provide the strongest degree of protection of resources using the native capabilities of the CPU. Strong resource isolation is a key enabler for achieving high availability.

 Robustness

Because Separation Kernel Hypervisors serve as the central host of the computing platform, they are designed specifically to be highly reliable and resilient to malicious techniques of subversion. Separation Kernel Hypervisors achieve this property by relying on simple least privilege internal designs with limited functionality and limited exposure to hosted software. Separation Kernel Hypervisors tend to be ten to hundreds of times smaller than monolithic operating systems.

 Determinism

Separation Kernel Hypervisors provide the ability to control explicit execution schedules for guest operating systems and bare-metal applications. Coupled with the ability to isolate resources for software modules, Separation Kernel Hypervisors can guarantee the availability of a system, ensuring any critical application can never be pre-empted or starved by competing applications. The deterministic control Separation Kernel Hypervisors have over a computing platform is a key enabler for designing highly reliable systems.

 Certification

Separation Kernel Hypervisors are designed to support environments that face both security and safety regulation. Relying on the intrinsic properties and core capabilities of a Separation Kernel Hypervisor system architects are given the tools needed to design and implement


Alain Soyer
email: alain.soyer@impmc.upmc.fr

Why not a Crystallographic Mark-up Language ?

Since 1991 CIF format (http://www.iucr.org/resources/cif/documentation) has proved to be very useful to crystallographers to exchange their data all over the world. In parallel to its popularization, the XML language and its derivatives (particularly HTML) has become universally adopted, with the huge development of internet.

In view of this evolution the following question arise : why not a Crystallographic Mark-up Language CrysML ? (I don't call it CML because Chemical Mark-up Language already exist).

Despite its quality, CIF have some inconveniences in comparison with XML: the most important is probably that it is not "object oriented", and also that CIF files are not a "well formed" documents. So I was wondering if it is not a good idea to rewrite CIF in XML format in the future.

Below is a first small file quartz.xml (created by hand with a basic vi editor !) : of course it is not a true valid crystallographic file, but just a piece of example to show what a CrysML file would look like . You may open this file in your browser.

One may note that :

-each block of data is delimited by an open <tag> and have a corresponding close </tag>, so a CrysML file seems more "robust" than CIF. A bloc corresponds to an "object" (in the meaning of computer language) and will probably be represented by a "structure" (in C or FORTRAN language) with the same organisation in memory of programs that will read or create CrysML files.

-tag names may be identical to pieces of CIF names and consequently familiar to crystallographers. An exception is for CIF "loop" to be replaced by list of items. I have added an "attribute" named length to indicate the number of items in a list. I know that this is not mandatory but I think that it is a "good practice" because a program reading the file can perform dynamical memory allocation of an array of structures to store the items of the list (and also may verify that the number of items really in the list is equal to the number announced in the attribute).

After quartz.xml is a second file CrisML_schema.xsd, referenced in the first file, containing a very rudimentary and incomplete "XML schema" , to play the role of the CIF dictionary.

If such an evolution is considered, the good news is that it will be quite easy to add an option to create XML files in a current software that creates CIF files. Modifying programs that read CIF files to support CrysML files will need a more important work (but I think it is probably less difficult to get data you are interesting from a XML file than from a CIF one). Of course the bad news will be the need to create an XML schema to replace CIF dictionary, witch is certainly a very tedious important work. type="pagesType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="pagesType"> <xsd:sequence> <xsd:element name="first" type="xsd:positiveInteger"/> <xsd:element name="last" type="xsd:positiveInteger"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="publType"> <xsd:sequence> <xsd:element name="section" type="sectionType"/> <xsd:element name="author_list" type="author_listType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sectionType"> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="author_listType"> <xsd:sequence> <xsd:element name="author" type="authorType" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="length" type="xsd:positiveInteger"/> </xsd:complexType> <xsd:complexType name="authorType"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="address" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="dataType"> <xsd:sequence> <xsd:element name="chemical" type="chemicalType"/> <xsd:element name="space_group" type="space_groupType"/> <xsd:element name="cell" type="cellType"/> <xsd:element name="atom_site_list" type="atom_site_listType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="chemicalType"> <xsd:sequence> <xsd:element name="formula" type="xsd:string"/> <xsd:element name="compound_source" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="space_groupType"> <xsd:sequence> <xsd:element name="crystal_system" type="crystal_systemType"/> <xsd:element name="name_HM" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="crystal_systemType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Triclinic"/> <xsd:enumeration value="Monoclinic"/> <xsd:enumeration value="Orthorombic"/> <xsd:enumeration value="Tetragonal"/> <xsd:enumeration value="Trigonal"/> <xsd:enumeration value="Hexagonal"/> <xsd:enumeration value="Cubic"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="Space_groupType"> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxInclusive value="230"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="cellType"> <xsd:sequence> <xsd:element name="lengths" type="lengthsType"/> <xsd:element name="angles" type="anglesType"/> <xsd:element name="volume" type="xsd:float"/> <xsd:element name="formula_units_Z" type="xsd:positiveInteger"/> <xsd:element name="measurement" type="measurementType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="lengthsType"> <xsd:sequence> <xsd:element name="a" type="lengthType"/> <xsd:element name="b" type="lengthType"/> <xsd:element name="c" type="lengthType"/> </xsd:sequence>