White Paper. RTOS Considerations for Unmanned Air Vehicles

Transcription

1 RTOS Considerations for Unmanned Air Vehicles

2 Table of Contents 1. Introduction 3 2. UAV History 3 3. UAS - Unmanned Airborne System Certification Authority Outlook 6 5. Multicore Processor Dilemma 7 6. RTOS Considerations 7 7. PikeOS Multicore Safety - Security 8 8. References 10 2

3 1. Introduction This white paper considers all aspects of autonomous unmanned aircraft, where autonomous means that the generic term unmanned air vehicle (UAV) has the capabilities built into the operational flight program (OFP) to be able to fly without human intervention. This paper will try to provide a historical progress of UAV technology, as well as combat aircraft (UCAV) through to modern perceptions and a look at future technology for autonomous drones. The key aspects of this white paper is Real Time Operating System (RTOS) consideration for autonomous drones now and in the future, where existing and future drone aircraft will require some form of safety certification, if they are to be allowed to fly along side commercial aircraft or operating from commercial airports this is a key consideration for existing Aircraft Collision Avoidance Radar Systems (ACARS), which are under test now for deployment in the near future. Other aspects of this white paper shall look at the latest System on Chip (SoC) technologies with multiple cpu cores or multi-core, that can all share devices and memory in the SoC, core contention for resources and solving interference issues in the SoC to deliver deterministic solutions through use of reliable RTOS architectures. This white paper will use a number of external references marked as [XX], where xx is a number to identify all references found at the end of this white paper. This white paper does not cover the use of unmanned aircraft algorithms or artificial intelligence or deep machine learning incorporated in the future or the dilemma of unmanned systems armed for a specific reason, but does provide an overview of possible system architectures and RTOS considerations for future drone technology to ensure safe and secure operation. 2. UAV History I seem to remember working on the Barracuda project in Germany around 2004, where I first heard about UAV technology and was involved in making MIL STD 1553 interface libraries non deterministic, as well endian proofing to allow reuse on different hardware architectures. The Barracuda project was a fully autonomous unmanned air vehicle, which may be surprising, as it was around thirteen years ago! [1] This was my first introduction or concept shift to UAV platforms of the future, some of these made it to production, but a lot failed to make the grade. Of course, there are more than just UAV projects these day, there is a lot of news about self driving cars, trucks, taxis, trains, submarines and even plans for cargo and military shipping to be unmanned in the future. We have all heard about reaper drones used during various campaigns over the last few years, these larger drones are here to stay and will have autonomous capabilities added as they are developed further. 3

4 However, next or other generation drones have taken on new roles for future operational requirements, where technology using Swarming drones will be used with initially manned aircraft to control a number of forward operating drones to take out ground and air defenses. This has been proven by companies such as DARPA and QinetiQ already. Eventually, this technology will be fully autonomous, with humans keeping a watchful eye, as swarming drones are used to perform their missions autonomously in swarms. [2] One of the most interesting stories recently is the integration of UAV within the Air Traffic Management System (ATMS), where initially the concept shall be kept around 400 feet to ensure cooperation with low level human flown craft and unmanned craft. The term Unmanned Aircraft System Traffic Management (UTM) is now under research by NASA and FAA. [3] However, already there are visions where high altitude UAS might be integrated into controlled airspace with commercial aircraft [4], where the safety of many civilians needs to be addressed and of course implementation of collision avoidance systems on UAV. (Fig.1: UAS Integration in the NAS Project) 3. UAS - Unmanned Airborne System. So let's consider what a UAS might actually be in terms of system architecture to allow us to understand the future consequences of UAS use, security and safety requirements of such systems. Past experience with autonomous UAV systems in early 2000, shows that any flight control algorithm must use deterministic sensor and control interfaces to ensure that the mission and flight control computers are able to affect control of the UAV in both a real time and in a determinist way. 4

5 Remember that Autonomous unmanned aircraft were being flown in early 2000, the technology may be much more advanced that we can ever know, unless we are involved in such programmes. So let's consider what UAS technology might look like to get a basic understanding of their capabilities, before we delve into RTOS, multicore architectures, safety certification and of course security to protect investments. A simplified view of the system architecture is provided in Figure 1.0, which provides a very simplistic view of a possible system architecture to include mission management, flight control, communications and perhaps even payload management. Sensors, Radar, GPS, ESM, ACARS COMMS Flight Control Computer Mission Computer Comms Computer Actuators Actuators Payload Management Weapon Sensors Camera, Radar, IFF, RWR (Fig.2: Example UAS System Architecture) Figure 2 is an imaginary UAS, where the Flight Control and Mission Computers may be one system and may be double or triple redundant to allow control voting algorithms to ensure that one system failure does not result in loss of the aircraft or mission depending on the requirements of the flight. The Comms Computer might provide only updated mission data or telemetry data to a ground station. However, it may also allow a function to fly the aircraft from a remote station by satellite, a digital network, or other method, all of which may or may not be secured in some way. 5

6 The Payload manager would be in control of final weapon assignments and final launch of weapon based on the designed mission and or by control from a pilot at a ground station sending commands via the Comms Computer. The system may even implement ACARS (Automatic Collision Avoidance Radar System), Radar, ILS (Instrument Landing Systems) as well as ECM (Electronic Counter Measures) to protect the UAS from electronic attacks. This all sounds fantastic, but any number of failures, whether hardware or software, within the system might cause a catastrophic or mission system failure scenario, possibly with unintended loss of life in the air or on the ground. Don't get me wrong, of course all system manufacturers take care that their systems will perform to their mission requirements, but there are currently limited safety regulations at this, but this will change soon though... The complication these days is that many of these UAS are being considered or are under test now, to fly along side commercial aircraft, which might be interesting to see when landing and taking off from shared airports perhaps? Even the DOD (Department of Defense) has indicated that the F35 may be the last manned fighter jet to be produced. So unmanned systems are set to be the norm for all future military scenarios, which will impact civilian Air Traffic Management in the future, who knows how this will pan out? 4. Certification Authority Outlook The FAA's position has had to change in order to consider a large number of factors that may affect UAS systems with the formation of UAST (Unmanned Aircraft Safety Team) [5], which is modelled around CAST (Commercial Aviation Safety Team) and GAJST (General Aviation Joint Steering Committee) [6]. Aviation safety in the past has been enforced by the FAA and EASA (European Aviation Safety Authority), using a number of standards and regulations. These standards and regulations have forced system suppliers to meet environmental, hardware and software certification specifications and have been decisive in reducing accidents and saving lives. However, these standards are based on airborne computers that have been using single core processor systems with exhaustive hardware and software verification and validation of the system, as well as exhaustive auditing by the authorities to ensure that systems meet all requirements for safety. One of the key specification or standards, although entitled as considerations for airborne software systems and equipment certification is RTCA DO-178C, recently updated in December (The hardware equivalent is RTCA DO-254) DO-178C covers only single core processing systems at higher certification levels, which is historically derived from early processor technology. However, technology has undergone many changes over the last few decades. Especially, the use of object oriented software programming languages and System on Chip devices with multiple cores running at lower clock frequencies, instead of single cores running at higher clock frequencies. Add in new processor architectures from NXP, ARM and Intel, which provide a wide range of performance architectures using multicore processors (MCP), which meet criteria for a massive amount of applications in many domains including A&D (Aerospace and Defense). 6

7 In order to meet the changes in modern processor architectures, CAST recently issued an updated CAST 32A paper dealing with the use of multicore processors within commercial aviation aircraft, this is now impacting decisions for aircraft system updates and new designs in many regions of the world. The CAST 32A paper is available from the CAST reference [7]. 5. Multicore Processor Dilemma The latest multicore processing technology means more cores at lower operating frequencies and all cores share all resources in the system, this must be good for system performance and throughput with modern serial bus systems, right? Well, there are other consideration for Multicore Processor (MCP) systems, where a number of resources are shared between the cores, which instead of increasing performance, may actually reduce performance, where cores access devices on the same bus may cause core lockout meaning that one core can only access the resource, but other cores are effectively blocked until the resource is freed up again. This can cause non deterministic behavior in the system, which is a big NO NO within Autonomous systems, determinism is key for safety and Autonomous operation. Please refer to a previous paper where I talk about multicore certification and RTOS considerations. [8] 6. RTOS Considerations There are many RTOS available in the market, but only a handful might meet all of the requirements for multicore processors with interference channel management, safety and security. We will look at an RTOS called PikeOS from SYSGO AG, which has been certified on safety platforms across multiple domains, some even with multicore processor designs. SYSGO started PikeOS as a research project in 2003 to provide a safety certifiable hypervisor product with separation microkernel. This project started with safety as a primary goal, where hypervisor based hard real time schedules will be met, as well as providing software guests OS with time and resource partitioning. Also known as Temporal and Space Partitioning. It s important to understand that there may be some interesting use cases for a Hypervisor based RTOS for consolidation of multiple processing systems into one processor system or even adding existing legacy systems as Guest OS on top of the Hypervisor RTOS. PikeOS Hypervisor Technology PikeOS is a safe and secure Hypervisor based RTOS with separation microkernel, very small SLOC (Source Lines Of Code) count, which is essential for safety applications with respect to verification and validation efforts for safety certification, where cost is determine by requirements and SLOC counts. PikeOS supports a number of guests or guest OS in partitions, which are time and resource partitioned, where robust partitioning is the major goal of PikeOS to ensure proper separation. However, this also has to be backed up with partition analysis for certification of systems! Guests include ARINC 653, Ada, PikeOS Native, POSIX, Linux, AutoSar, RTEMS, Java and Android. PikeOS supports both software and hardware virtualization. Hardware Virtualization shall not be discussed further in this white paper, but will be the discussed in future white papers from SYSGO. All major Processor architectures are supported. However, an MMU is required by PikeOS RTOS. 7

8 Figure 3 provides an illustration of the PikeOS system architecture. The PikeOS architecture in Figure 3 is split between User Space and Supervisor Space. (Fig.3: PikeOS Architecture) We can see the Hypervisor along with the ASP (Architecture Support Package) and the PSP (Platform Support Package) operate in supervisor space, where the PSSW and Guest partitions along with user applications are working in use space with no privileges. The exact architecture of PikeOS must be defined at design time using the SYSGO CODEO an eclipsed based IDE. CODEO also allows definition of the processor core that each partition may be executed on, which may be one core or many cores, depending on the system requirements, as well as communication channels, messages queues, partition schedules, partition privileges and much more. PikeOS and CODEO are complete solutions for implementing safety and secure embedded systems, follow the references, much more details can be found directly by contacting SYSGO AG at embedded World PikeOS Multicore Safety - Security How does PikeOS provide a deterministic system for safety certification with MCP systems? The key point of PikeOS is robust partitioning with time, resource and core separation by time schedules split across partitions and also across multiple cores in SMP (Symmetric MultiProcessing) mode. All Partition actions are limited to what has been defined at design before PikeOS actually executes. PikeOS does not allow dynamic allocations and all illegal memory, device IO or invalid communication attempts are blocked by PikeOS with Health Monitoring built in for event data. A special partition may have privileges to start, stop, cold or warm boot suspect partitions, which may be interesting for a compromised system from a security perspective. Figure 4 illustrates a possible core schedule for a safety critical system in an MCP system. 8

9 The RED partition is defined using Time Scheduling, as well as only being able to run only on Core C at runtime. The important point is that the RED Partition will be running on Core C with no other cores active, which eliminates any cross core interference with cache, memory and device IO. (Fig.4: Possible core schedule for a safety critical system in an MCP system) So how can we prove PikeOS for certification? It s an interesting question and is addressed partially in the [7] by the CAST 32A paper. Robust Partitioning is referenced in the CAST 32A paper in 25 instances with respect to MCP approach to certification. The PikeOS certification kit provides the key parts of DO-178 requirements with respect to requirements, design, even source code is available in various options. The key documents in the cert kit are the Partition Analysis, Stack Analysis and WCET (Worst Case Execution Time) Analysis, which are generated from test suites run on the actual system runtime configuration as well as high level Requirements, Design, Test Specifications, verification test procedures cases and a Safety Manual. However, this list is not exhaustive and many more documents may be available for audit by certification authorities. 9

10 Conclusion Unmanned Airborne Systems operating with multi core processor systems look sure to be deployed for the future, especially military based unmanned air vehicles with weapons on board or even swarming drones controlled by manned aircraft or ground stations or even Autonomously It s clear with the FAA forming UAST that certification requirements for all unmanned flying platforms above determined weights, will become the norm. The MCFA (Multi Core For Avionics) reference [9] was started early 2013 to address multi core systems in avionics, multi core is the future for avionic systems, whether civilian or military, manned or unmanned. The MCFA are working together with the aircraft certification authorities to help ensure successful multi core use for the future. With this in mind, there are many RTOS available in the market place, but only a few that might be candidates for certifiable unmanned system platforms. PikeOS is offering technology and know how for the certification of multi core in avionics and many other domains, where SYSGO have already certified a PikeOS multi core system to EN50128 to SIL4 on safety critical train systems. PikeOS is a good candidate as an RTOS for UAV with the added benefit that PikeOS is a non ITAR RTOS with source code availability for certification requirements of the future. PikeOS Hypervisor technology ensures robust partitioning, as required by the FAA CAST 32A paper, as well as security features for a safe and secure RTOS offering. So embedded goes Autonomous has been happening since early 2000 and the future is further Autonomy, it will be interesting times over the next few years. I recently noticed this article back in September 2017 and is an indication of the advances being made [10]. Visit and find out more or contact me directly by Robert.pickles@sysgo.com 8. References The following reference material was used in the creation of this white paper. [1] [2] [2a] [3] [4] [5] [6] [7] [8] ( System on Chip Certifiable OS Solution by Robert Pickles) [9] [10] 10