WO2016102055A2 - Procédé pour faire fonctionner un composant de commande pour un aéronef et composant de commande - Google Patents

Procédé pour faire fonctionner un composant de commande pour un aéronef et composant de commande Download PDF

Info

Publication number
WO2016102055A2
WO2016102055A2 PCT/EP2015/002542 EP2015002542W WO2016102055A2 WO 2016102055 A2 WO2016102055 A2 WO 2016102055A2 EP 2015002542 W EP2015002542 W EP 2015002542W WO 2016102055 A2 WO2016102055 A2 WO 2016102055A2
Authority
WO
WIPO (PCT)
Prior art keywords
processor core
applications
processor
software
core
Prior art date
Application number
PCT/EP2015/002542
Other languages
German (de)
English (en)
Other versions
WO2016102055A3 (fr
Inventor
Laurent Dieudonné
Alexander Bollwein
Jürgen MARTIN
Original Assignee
Liebherr-Aerospace Lindenberg Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Liebherr-Aerospace Lindenberg Gmbh filed Critical Liebherr-Aerospace Lindenberg Gmbh
Publication of WO2016102055A2 publication Critical patent/WO2016102055A2/fr
Publication of WO2016102055A3 publication Critical patent/WO2016102055A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/4028—Bus for use in transportation systems the transportation system being an aircraft

Definitions

  • the invention relates to a method for operating a control component for an aircraft, in particular in the form of a flight control and / or suspension control system.
  • this architecture is not used for vital system functions with high-security requirements, but instead for applications with lower security requirements, such as visualization, radar, etc., or for applications with even lower criticality.
  • the IMA architecture can be mentioned.
  • the main focus is on performance, combined with reasonable but not maximal security: the performance is strongly associated with the high clock frequency that can only be achieved with small transistor feature size ( ⁇ 60nm) or with active heat dissipation which, in both cases, negatively affects the security of the system, and eliminates some hardware integrity mechanisms in favor of performance mechanisms (cache, complex branchprediction, pipelines, etc.), aggravating the phenomenon, to compensate for it, and to To achieve sufficient security, several high-performance computers are combined (redundancy). For both architectures, however, more and more integration of new, more complex or security-relevant functions is required. At the same time, however, the requirements for energy savings, weight and space have increased significantly more. Since no major progress in the development of single-core processors is to be expected in the near future, the performance increase of the single-core processors will not meet the increasing requirements in the future.
  • the object of the present invention is to provide an optimized method for operating a control component for an aircraft, which can meet the growing demands in the future.
  • a method for operating a control component for an aircraft is proposed according to claim 1, which for the first time relies on a multi-core processor for the parallel execution of safety-critical avionics applications.
  • a possible control component for an aircraft is preferably a flight control or suspension control system.
  • the method according to the invention makes use of a multi-core processor whose architecture comprises at least one system bus and at least one I / O peripheral bus which is separate from it.
  • the strict physical separation of the two bus components is required to avoid processing delays of the applications to be executed due to parallel bus access to I / O peripherals.
  • at least one or more processor cores of the multi-core processor are used as so-called application processor cores on which different avionics applications can be executed in parallel.
  • At least one other processor core is used as a so-called dedicated I / O processor core, which manages the administration of the I / O peripheral buses takes over and manages the access of the at least one application or application processor core to the I / O peripheral bus.
  • the I / O processor core can monitor the correct operation of the platform in a so-called central 'Health Monitoring' function.
  • the inventive principle is based on a separation between the 10- activities and the execution of the applications. This allows correct synchronization of the IO activities, i. Simultaneous access attempts of the applications to the common IO periphery can be reliably avoided.
  • the strict separation enables, in particular, a deterministic time-controlled operation of the application requests to the IO resources. This mode of operation is simplified in that only a single processor core, namely the dedicated I / O processor core, accesses the IO resources. Consequently, the resulting bus load can be planned and controlled with sufficient accuracy, which ensures the predictability of the IO accesses.
  • a software framework with dedicated architecture and mechanisms enables the deterministic and segregated execution of applications in parallel on at least two or more application processor cores, and manages and synchronizes the accesses of the applications to the peripheral bus by means of a dedicated processor core corresponding to that role is configured as a dedicated I / O processor core.
  • the software framework is advantageously an SAMP architecture, also referred to as "synchronized asymmetric multiprocessing.”
  • SAMP architecture has a specific role assigned to core processor cores deterministic and centralized communication with the I / O peripherals via exclusive access to these peripherals through the separate management of the peripheral bus.Another major role is the deterministic execution of the software application within dedicated partitions and with its own real-time operating system per processor core. It is particularly preferred if the method according to the invention provides segregation of the executed applications, in particular based on a combination of software and hardware function. Segregation is required to prevent cross-application propagation of software or hardware errors. In particular, the segregation provides a space and / or time partitioning between the running applications. With shared hardware resources, mutual interference is prevented by means of dedicated software architecture, software mechanisms and software functions based on existing hardware mechanisms.
  • each application is executed in only one partition, each partition being executed on only one application processor core.
  • a partition consists of reserved memory parts and reserved CPU execution windows. This limitation allows a manageable sharing of the processor architecture resources available, providing better predictability in the execution of the applications as compared to conventional solutions where the applications run on multiple partitions and multiple processor cores.
  • Functional shared resources include hardware service functions such as CRC modules, safety modules, encryption modules, and BIT modules.
  • CRC modules hardware service functions
  • BIT modules hardware service functions
  • the proxy application is preferably equipped with exclusive rights for accessing the common resource and can manage accesses of the further applications by means of scheduling methods.
  • one or more internal functional shared resources between applications can be managed deterministically.
  • IVI mechanisms are, for example, bus arbitration mechanisms, segregation mechanisms, such as, for example, a memory management unit (MMU) or an IVImory protection unit (MPU), semaphore modules, etc.
  • MMU memory management unit
  • MPU IVImory protection unit
  • non-functional resources such as the system bus, the shared memory, a FLASH memory, etc.
  • native mechanisms of the multi-core processor are preferably used, combined with a kernel scheduling service.
  • resources that are spatially separable such as the shared memory, parts of it are assigned to the applications or partitions and secured thanks to segregation mechanisms such as MMU / MPU.
  • application accesses are organized in the form of time windows with data and access budgets on each resource, taking into account the resource bandwidth, to the temporal usage plan of those resources create.
  • each application processor core For spatial partitioning, it is expedient for each application processor core to have its own RAM allocated in partitioned form to the hosted applications of the processor core. Furthermore, it is preferred if each application processor core includes its own protection mechanism in order to enable secure access and a corresponding secure allocation of its RAM memory to individual applications. Through this protection mechanism, the RAM memory is separated from the remaining application Processor cores intangible. Suitable protection mechanisms are MMU / MPU. Thanks to the processor architecture used, memory accesses of the executed applications can also be realized without using the system bus. This guarantees a clean spatial separation between the individual application processor cores and also strengthens the ability to implement a deterministic operating routine of the resulting control component. The implemented space protection mechanism in the form of the MMU / MPU is used for the spatial separation between the applications within the same processor core.
  • each processor core in particular each application processor core, to comprise at least one own interrupt controller with timer function and / or at least one separate watchdog function.
  • This allows a time interrupt to be generated independently of the remaining application processor cores. This allows time control for the execution of the applications or services managed by the respective application processor core.
  • the watchdog function which is independent of the timer function, allows a reliable prevention of processor-propagating error propagation if a timeout or a deconfiguration of the interrupt controller occurs due to external disturbances.
  • At least one processor core of the multi-core processor is implemented as a safety processor core.
  • a corresponding safety processor core comprises at least two redundantly operating processor cores on which the same program code, in particular the same application and / or the I / O management and / or the "health monitoring" function, is executed Ideally, at least one of the redundant processor cores is operated offset in time by at least one operating cycle, in particular by an artefact, in order to reliably detect a malfunction of a processor core of the safety processor core. operated delay cycle so that short-term external interference, for example by radiation, do not lead to an identical error pattern in the redundant processor cores.
  • the safety processor core is used to execute highly critical applications. Ideally, at least one safety processor core is used to execute one or more monitoring functions of the entire control component or of the honorkeeping processor itself. In this context, in addition to the monitoring, the execution of one or more recovery or failsafe functions is conceivable. In the same way, basic system functions of the control component with the highest security level can be executed on such a safety processor core.
  • each application processor core and / or the dedicated I / O processor core runs its own operating software.
  • the operating software preferably comprises a kernel, an inter-partition communication layer for taking over the logical routing of the signals at the partition level, and an inter-processor core communication layer for taking over the physical routing of the data between different processor cores, wherein preferably the routings are defined Schedule with time window for each partition to be performed.
  • the inter-partition and / or inter-processor core communication preferably takes place by means of a shared memory to which the applications of different processor cores have access.
  • At least one pseudo-partition with I / O queues is installed on the at least one dedicated I / O processor core, which is preferably executed within the inter-partition communication layer of the dedicated I / O processor core.
  • the pseudo-partition serves to manage incoming accesses of the applications, ie the application processor cores, and to ensure their integrity.
  • the pseudo-partition also serves to send the data received from the I / O peripherals to the correct application (from the application cores) in corresponding mail boxes (via shared memory) to transfer configuration plan.
  • the configuration of the control component in particular the configuration of partitions and pseudo-partitions with respect to scheduling, I / O use (rights, amount of data, temporal aspects) and inter-partition communication by means of a project-specific configuration file on the platform is uploaded with the project SW applications.
  • the application's I / O access requests are sized in accordance with the capacity of the I / O resources, the buses, the memory used, and the performance of the dedicated I / O processor core, so these resources can never be overloaded during operation.
  • a defined software interface is provided between the executed applications and the operating software of the individual application processor cores.
  • the interface recommended in particular is the well-known standard ARINC653.
  • actuators for different areas may be grouped together on an execution platform designed according to the invention method.
  • the present invention relates to a control component for an aircraft, in particular in the form of an aircraft and / or chassis control of an aircraft, with at least one multi-core processor and a software architecture for performing the method according to the invention.
  • the control component is characterized by the same advantages and properties as the method according to the invention, which is why a repetitive description is omitted here. It should be noted that the method according to the invention or the control component can be used not only in avionics, but generally in all applications with safety-critical requirements, so also in particular in railway technology.
  • FIG 1 an overview of the control platform according to the invention with its essential concepts
  • Figure 2 an illustration of the platform architecture according to the invention.
  • the present invention is concerned with the ability to group and execute multiple safety-critical software applications on a control component for an aircraft with a single multi-core processor.
  • the currently most powerful multi-core processors are mostly developed for non-safety-critical domains such as telecommunications or consumer electronics (PC, entertainment) and therefore do not offer all the necessary features for safety-critical domains regarding determinism, segregation and safety.
  • Their architecture is mostly designed for average performance rather than deterministic performance, much less for running safety-critical applications.
  • the transistor structure size of these processors is less than 45nm, which is very sensitive to radiation from aircraft and automobiles.
  • the invention enables a physically-segregated execution of safety-critical functions as required. with independance requirements and a grouping of functions without independance requirements.
  • FIG. 1 gives an overview of the platform with its essential concepts.
  • the configuration of the platform is designed by the project software architect and stored in at least one configuration file 10.
  • This file contains information on how many partitions are needed on which processor core and which application should be in which partition. It also contains a definition of the communication plan, i. which component at which time with which components which data in which quantity may exchange.
  • the software applications 20 for implementing a single function of the control component for example in a flight control system the controls of actuators for different areas, monitors for certain system functions of the flight control and maintenance applications are prepared based on an ARINC 653 API.
  • the configuration file 10 and the SW applications 20 are loaded onto the platform 1.
  • the platform 1 is configured according to the configuration file 10.
  • the platform 1 is based on a multi-core processor whose hardware is adapted by a dedicated software architecture to the requirements of avionics technology, in particular safety requirements.
  • the platform is built on a multi-core processor having a number of N + 1 processor cores.
  • N processor cores provided in the diagram of Figure 1 with the reference numerals 30, 31, are used as so-called application processor cores, which are responsible for the execution of the SW applications 20.
  • Each application processor core 30, 31 comprises its own memory which can be divided into different parameters. 32 is split.
  • a partition is defined by a reserved / protected memory area, which also includes execution windows per processor core.
  • Each processor core performance is partitioned using a guaranteed time window.
  • the SW applications 20 are physically assigned to the partitions 32 of the application processor cores 30, 31 of the multi-core processor according to the configuration file 10 and executed by the processor cores 30 according to plan from the configuration file 10.
  • the architecture includes a physically isolated bus 50 for access to the I / O peripheral component 70 and a bus 60 for communication between the processor cores 30, 31, 40.
  • a processor core N + 1, designated by the reference numeral 40 is used for the platform 1, which is referred to below as the I / O processor core 40.
  • the inventive principle is therefore based on a separation between the I / O activities and the execution of the applications 20. It allows a correct synchronization of the I / O activities and sequential simultaneous access attempts of the executed SW applications 20.
  • the application requests to l / O - Resources 70 are operated according to the configuration plan 10 deterministic time-controlled. This is greatly simplified since only one processor core 40 accesses the I / O resources 70. As a consequence, the bus load can be scheduled and controlled, ensuring predictability of I / O accesses.
  • the platform 1 is designed such that each application 20 is executed in a partition 32 and that a partition 32 is executed on only one core 30, 31. These limitations allow a manageable allocation of resources and thereby a predictable execution of the applications 20 as compared to solutions in which the applications are executed on multiple partitions and multiple cores.
  • This configuration specifies the work of kernel 33, IPC 34 and 42 (including pseudo-partition 44) and ICG software layers 35 and 43.
  • the platform offers services such as scheduling, time and space protected partitions 32, communication between the applications 20, schedulable execution times of the read and write accesses to the I / O resources 70, etc.
  • the software applications 20 must be compatible with the API 36 offered by the platform.
  • a subset of the ARINC653 avionics standard is used as the standardized interface 36.
  • the software concept is shown in the illustration of FIG.
  • the software applications 20 run within partitions 32 that represent the segregated areas.
  • the I / O processor core 40 run pseudo-partitions 44 within the I / O core IPC layer 42, which exclusively the signal data of the partitions I / O accesses from the application processor cores 30, 31 via I / Manages O-queues and ensures their integrity.
  • the configuration of the partitions 32 and pseudo-partitions 44 with respect to scheduling, I / O use (rights, amount of data, temporal aspects) and inter-partition communication is defined by the project-specific configuration file 10 and on the platform 1 with the project SW applications 20 uploaded.
  • Each application core 30, 31 is equipped by a deterministic operating system in the form of a kernel 33 (LAOS: Liebherr Aerospace Operating System) which provides for the spatial and temporal segregation of the partitions 32.
  • LAOS Liebherr Aerospace Operating System
  • On the IO processor core 40 runs a slender real-time scheduler 41, which acts for the determinism of the accesses to the I / O resources 70.
  • Each "port” consists of a reserved memory buffer and a time window. in accordance with the configuration of the whole system 1 (see the "configuration file 10").
  • the I / O access requests of the applications 20 will be in accordance with the capacity of the I / O resources 70, the buses 50, 60 of the memory, and the I / O processor core performance dimensioned so that these resources can never be overloaded.
  • the adoption of the logical routing of the signals at the partition level is realized by the IPC 34 (Inter-Partition Communication) layer at the application processor cores 30, 31.
  • IPC 34 Inter-Partition Communication
  • the physical routing of the data between the various cores 30, 31, 40 is handled by the ICC (Inter - Core Communication) Layer 35, 43 taken over.
  • This layer 35, 43 knows on which core 30, 31 which partition 32 lies and sends the signals to the corresponding core 30, 31.
  • These layers 35, 43 also provide queues on, in which the signals from the applications 20 to be sent before the addressed target cores 30, 31 are located, and in which the signals are stored after receiving from other cores 30, 31 before they are taken over by the receiving applications 20.
  • Platform 1 requires a multi-core processor architecture that has a separate peripheral bus 50.
  • this type of architecture the communication between the processor cores 30, 31, 40 on a dedicated bus 60 ("system bus") and the communication between one processor core 40 and the I / O peripheral 70 on another bus 50 ("I / O -Bus"). Therefore, the peripheral accesses are not disturbed by the application communication, and vice versa the application communication is not disturbed by the peripheral accesses.
  • This advantage also exists compared to other architectures that use a single bus, too as a crossbar switch, offer. With separate buses 50, 60 the transfers are physically separated, while a crossbar switch still uses common components for the operation (data transfer, configuration) of the different clients and even has a limited number of crossbar channels.
  • Each of the separate buses 50, 60 may also be a crossbar switch.
  • the load on each bus 50, 60 is significantly easier to evaluate than with other architectures where all data transfer is done over a single bus.
  • the predictability of the signal transfer chain between the applications 20 and between applications 20 and I / O peripherals 70 via the respective buses 50, 60 is also much easier to ensure.
  • Platform 1 is based on the ARINC653 standard, which defines concepts for the determinism of communication.
  • the messages are transferred between applications 20 (hosted in partitions 32) through ports within the platform 1.
  • Each port represents an end of the transfer chain of a signal and defines the amount of data and period of transfer of that signal between partitions 32.
  • This principle is also applicable to multi-core processors where each processor core 30, 31 terminates the signal transfer chain via this communication Managed ports. Since each port is dedicated to a signal and each port is serviced by each processor core 30, 31 according to a time-based schedule, the entire transfer chain of each signal can be deterministically secured.
  • the determinism of accesses to the I / O peripherals 70 is based on the following principles: With the selected multi-core processor type, the data is transferred to the I / O peripherals 70 through a dedicated I / O bus 50. Thanks to the platform design, the management of the accesses of the applications 20 to the I / O peripherals 70 is realized by a single and dedicated I / O processor core 40. This dedicated I / O processor core 40 handles the synchronization between the common I / O peripherals 70 and the different partitions 32 from the application processor cores 30, 31 for timely sending and receiving of the data to / from the I / O Peripherals 70, as planned in the configuration file 10.
  • the schedule for sending or receiving each signal of the applications 20 is defined during the system configuration phase. This plan is made in accordance with the timing requirements of applications 20, I / O bus capacities 50, I / O peripheral bandwidth and response times, and I / O processor core performance. Supported by the processor architecture with separate I / O bus 50, the platform design can guarantee the predictability of I / O activity execution.
  • the predictability of access to internal shared resources is supported by the combination of multi-core processor architecture and platform design.
  • the internal functional common resources of the processor e.g. CRC modules, safety modules, BIT modules, etc. are exclusively managed (e.g., one per functional resource) via individual dedicated (platform) applications 21, which are allocated in a partition 32 on an application processor core 30.
  • each of these platform applications 21 has exclusive accesses to the corresponding functional common resource.
  • the other applications 20 delegate their desired work with these controller resources to this "proxy application 21.”
  • the use of these resources can also be performed according to a usage are designed during the configuration phase and are transmitted by means of the configuration file 10 to the various kernels 33 of the processor cores 30, 31.
  • these internal, functionally shared resources are deterministically shared between the other applications 20.
  • the multi-core processor must provide certain mechanisms.
  • the chosen multi-core processor architecture type provides specific mechanisms that act to ensure determinism in accessing internal shared resources. Exemplary are bus arbitration mechanisms, segregation mechanisms such as e.g. MMU / MPU, semaphore modules, etc. mentioned. During the configuration phase, these mechanisms are properly prepared in accordance with the needs of the applications 20 and their correct configuration is specified for implementation.
  • non-functional resources such as system bus 60, shared memory 80, FLASH, etc.
  • native multi-core processor mechanisms are used, combined with kernel 33 scheduling service.
  • resources that are spatially separable such as eg the shared memory 80, parts thereof are assigned to the applications 20 or partitions 32 and ensured by means of segregation mechanisms (MMU / MPU).
  • the uses are organized by the time slot applications 20 to create the temporal usage plan of those resources.
  • the spatial or temporal divisions of these resources are again in the configuration phase with the budgeting of the resources in accordance with the requirements of the applications 20 and the capacity of the resources where the data budgets and time schedules in the configuration file 10 are determined.
  • Seqreqation Segregation is space and time partitioning between running applications 20. Segregation is necessary to prevent the spread of errors (SW or HW). The segregation can be realized with different techniques, which are directly dependent on the properties of the (multi-core) controllers.
  • the platform's segregation concepts meet the requirements of the D0178B / C standard for partitioning and are based on the principles of ARINC653 for the implementation of partitions 32.
  • the D0178B / C requires that a software component:
  • - may share a hardware resource with other software components, if this software component can not influence any other component, in the case of any kind of errors derived from software or hardware source.
  • the component execution code, the I / Os, and the data storage of the components are considered in the partitioning specification 32.
  • the platform has been chosen with certain multi-core processor models that offer enhanced segregation capabilities.
  • the platform 1 software architecture and capabilities presented use and complement these hardware capabilities to ensure avionics standard compliant segregation.
  • platform 1 primarily utilizes the architecture of the selected multi-core processor, supplemented with software mechanisms: each application processor core 30, 31 must have its own RAM 37 used for the data of hosted applications 20. Thanks to this architectural feature, the data accesses of the executed applications 20 are also realized without the use of the system bus 60. This guarantees a spatial separation from the other processes sorkernen 30, 31 and also strengthens the Determinismus scholaren the platform 1. However, the communication with the other applications 20 of the other application processor cores 30, 31 is realized by means of the shared memory 80. Storage areas are reserved for each partition 32 and managed by the IPC 34 and ICC Software Layer 35.
  • Each application processor core 30, 31 must have its own space protection mechanisms 38, such as an MMU / MPU. This is necessary for the spatial separation between the applications 20 within the same application processor core 30, 31, comparable to single-core processors.
  • the MMU / MPU are also used for the communication mechanisms between the application processor cores 30, 31 to ensure the segregation of the communication channels by a shared memory 80.
  • the space protection mechanisms 38 are configured by the software kernels 33 (real-time operating system) to ensure the partition contexts. Thanks to an I / O processor core 40 dedicated to the I / O communication, the platform 1 can ensure the predictable and secure sharing of the I / O peripherals 70 and their supplying resources such as the I / O bus 50.
  • the I / O processor core 40 executes platform software 41, 42, 43, 44 developed at the highest level of criticality: it meets the requirements of avionics standards for segregating mixed-criticality applications to the highest criticality level enable.
  • the hardware semaphore module may be mentioned which is used for sharing resources in combination with software and other hardware functionalities.
  • Time partitioning For the time partitioning platform 1 uses necessary functionalities and architectural aspects of the specific selected processors. They also need to be combined with appropriate platform software:
  • Each processor core 30, 31, 40 must have its own interrupt controller with timer function as well as a separate watchdog function, among others. to be able to generate a time interrupt independently of the other processor cores 30, 31, 40. In particular, this allows time control for the execution of the applications 20 or services hosted by each application processor core 30, 31.
  • the timer independent watchdog also prevents error propagation outside the single processor core 30, 31 if a timeout or deconfiguration of the interrupt controller of a processor core 30, 31 appears for some reason (e.g., SEU / MBU due to radiation).
  • the kernel 33 can offer time partitions by means of a scheduler.
  • Each processor core 30, 31 is populated with a kernel 33, independent of other processor cores 30, 31, to enable segregation for the timed execution of the hosted applications 20.
  • the application processor cores 30, 31 are only controlled with a time interrupt (and the error watchdog) by means of the kernel 33 and delegate all external HW interrupts to the dedicated I / O processor core 40, if necessary. This allows easier time partitioning and predictability of the running applications 20.
  • a dedicated I / O processor core 40 simplifies the time partitioning for the application processor cores 30, 31 with respect to access to I / O peripherals 70.
  • a scheduling plan must be established for communication with the I / O devices 70 and with the applications 20, in accordance with the timing communications requirements of the applications 20, with the I / O bus capabilities, with the I / O - Peripheral bandwidth, and with the performance of the IO processor core.
  • the kernel 41 of the I / O processor core 40 operates in principle only with the time interrupt (and with the watchdog interrupt for the error coverage). In some cases, however, there may be a need for some I / O peripherals 70 to be interrupts. In this case, the time required to execute the interrupts is scheduled in the scheduling plan, as well as an interrupt budget fixed. This interrupt budget corresponds to a maximum allowed number of interrupts per signal within one L / O processing cycle. If the interrupt budget of a signal is consumed, this interrupt is disabled by the kernel 41 until the end of the I / O processing cycle.
  • the security concepts of the multi-core platform 1 use the specific architecture and functionalities of the selected multi-core controller models, supplemented as required with software functionalities. These controller models offer the following features:
  • Integrity check of the memory elements eg against SEU / MBU problems (volatile memory disturbances cause tilted bits as consequences of radiation), or in general: o At least one safety processor core 30 with lock-step mode for the detection of SEU / MBU faults.
  • a safety processor core 30 consists of two processor cores: one for the user (ie the application) visible processor core 30, and a second identical but user hidden processor core 30a running parallel to the visible processor core 30 executing the same binary code , The hidden processor core 30a is offset a few cycles from the visible processor core 30 so that the radiations do not cause the same effect on the same bits. Subsequently, the results of the two processor cores 30, 30a are compared by hardware and a system exception is generated in the event of differences.
  • ECC Error Correction Code
  • EDC Error Detection Code
  • 80 at least ParityCheck 39, 80 are present on all HW elements which contain RAM (also combinable with the processor cores 30, which are connected by means of the lock-out).
  • Step mode safety processor core 30
  • o Core-Local MMU / MPU 39 allows independence of realization of segregation between processor cores 30, 31 for the hosted applications 20.
  • MMU / MPU registers are also protected against SEU / MBU with lock-step mode o Bus protection / monitoring modules to protect or detect the internal and I / O peripherals against unwanted access.
  • the different capabilities of the multi-core controller models are used selectively.
  • the following applications 20 are executed: the monitoring of the platform functions (eg for the health monitoring as defined in the ARINC-653) ) and the failsafe reactions of the system.
  • the monitoring of the platform functions eg for the health monitoring as defined in the ARINC-653
  • the failsafe reactions of the system e.g.: o clock and voltage monitors o deactivation of applications 20 / partitions 32 / processor cores 30, 31, when Kemel 33 executed by a non-safety processor core 31 itself is no longer feasible
  • o Failure Reporting features the system functions that request the highest levels of security. For example:
  • o System monitors eg the monitoring of Catastrophic classified system functions, the Communication Integrity monitors, etc.
  • Service for hardware functions that affect the integrity of the system eg CRC calculation services, built-in test functions, configuration functions, etc.
  • Voting functions o Applications whose results are widely propagated ie to several other applications or I / O peripherals
  • the platform 1 offers opportunities to respond to errors according to the avionics standards and the project specifications, such as a recovery of the affected applications 20 or the execution of the failsafe mode application. This is realized with a combination between the kernels, specific platform and project applications 20.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Safety Devices In Control Systems (AREA)
  • Control By Computers (AREA)
  • Multi Processors (AREA)
  • Hardware Redundancy (AREA)

Abstract

l'invention concerne un procédé pour faire fonctionner un composant de commande pour un aéronef, comportant un cadre d'applications et au moins un processeur multicœur pour l'exécution parallèle d'applications avioniques essentielles à la sécurité, l'architecture de processeur comprenant au moins un bus système et au moins un bus périphérie séparé du précédent, et selon ledit procédé, des applications parallèles étant exécutées sur au moins deux noyaux de processeur d'applications et l'accès au bus périphérie étant géré par un noyau de processeur E/S dédié.
PCT/EP2015/002542 2014-12-23 2015-12-16 Procédé pour faire fonctionner un composant de commande pour un aéronef et composant de commande WO2016102055A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014019531.7 2014-12-23
DE102014019531.7A DE102014019531A1 (de) 2014-12-23 2014-12-23 Verfahren zum Betrieb einer Steuerungskomponente für ein Luftfahrzeug sowie Steuerungskomponente

Publications (2)

Publication Number Publication Date
WO2016102055A2 true WO2016102055A2 (fr) 2016-06-30
WO2016102055A3 WO2016102055A3 (fr) 2016-09-22

Family

ID=55173816

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/002542 WO2016102055A2 (fr) 2014-12-23 2015-12-16 Procédé pour faire fonctionner un composant de commande pour un aéronef et composant de commande

Country Status (2)

Country Link
DE (1) DE102014019531A1 (fr)
WO (1) WO2016102055A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110781055A (zh) * 2019-10-15 2020-02-11 中国航空无线电电子研究所 一种嵌入式分区实时操作系统的服务组件运行状态监控方法
CN111108471A (zh) * 2017-09-19 2020-05-05 标致雪铁龙汽车股份有限公司 用于确保机动车辆的多核处理器的数据的稳定性的方法
CN112241352A (zh) * 2020-11-03 2021-01-19 中国航空工业集团公司西安航空计算技术研究所 一种网格化容错计算机平台的监控系统
CN115509986A (zh) * 2022-09-28 2022-12-23 美的集团(上海)有限公司 核间通信方法、电子设备及存储介质

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11254441B2 (en) * 2018-11-29 2022-02-22 Hamilton Sundstrand Corporation Aircraft controller including multiple core processor with wireless transmission prognostic/diagnostic data capability
US11097857B2 (en) * 2018-11-30 2021-08-24 Hamilton Sundstrand Corporation Multiple core motor controller processor with embedded prognostic/diagnostic capabilities
CN110597754B (zh) * 2019-08-02 2023-02-21 北京多思安全芯片科技有限公司 一种主从式安全处理器
DE102020213371A1 (de) 2020-10-22 2022-04-28 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung und Verfahren zur Steuerung eines technischen Systems
DE102021209627A1 (de) 2021-09-01 2023-03-02 Robert Bosch Gesellschaft mit beschränkter Haftung System und Verfahren zum Ausführen von funktional gleichen Applikationen

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2583437B1 (fr) * 2010-06-17 2015-07-29 Saab AB Systeme et methode d'avionique distribuee

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111108471A (zh) * 2017-09-19 2020-05-05 标致雪铁龙汽车股份有限公司 用于确保机动车辆的多核处理器的数据的稳定性的方法
CN110781055A (zh) * 2019-10-15 2020-02-11 中国航空无线电电子研究所 一种嵌入式分区实时操作系统的服务组件运行状态监控方法
CN110781055B (zh) * 2019-10-15 2023-03-10 中国航空无线电电子研究所 一种嵌入式分区实时操作系统的服务组件运行状态监控方法
CN112241352A (zh) * 2020-11-03 2021-01-19 中国航空工业集团公司西安航空计算技术研究所 一种网格化容错计算机平台的监控系统
CN112241352B (zh) * 2020-11-03 2023-10-20 中国航空工业集团公司西安航空计算技术研究所 一种网格化容错计算机平台的监控系统
CN115509986A (zh) * 2022-09-28 2022-12-23 美的集团(上海)有限公司 核间通信方法、电子设备及存储介质
CN115509986B (zh) * 2022-09-28 2024-05-07 美的集团(上海)有限公司 核间通信方法、电子设备及存储介质

Also Published As

Publication number Publication date
WO2016102055A3 (fr) 2016-09-22
DE102014019531A1 (de) 2016-06-23

Similar Documents

Publication Publication Date Title
WO2016102055A2 (fr) Procédé pour faire fonctionner un composant de commande pour un aéronef et composant de commande
DE112011105298B4 (de) Reduzieren des Energieverbrauchs von Uncore-Schaltkreisen eines Prozessors
DE68913629T2 (de) Satzverriegelungsprozessor für vielfachverarbeitungsdatensystem.
DE102013214756B4 (de) Verfahren zum verwalten einer task-ausführung in einem mehrkernprozessor
DE69735575T2 (de) Verfahren und Vorrichtung zur Unterbrechungsverteilung in einem skalierbaren symmetrischen Mehrprozessorsystem ohne die Busbreite oder das Busprotokoll zu verändern
DE3856030T2 (de) Vorrichtung und Verfahren zur Durchführung von änderbarer Betriebsmittelaufteilung in einem Datenverarbeitungssystem mit zentralen Datenverarbeitungseinheiten mit verschiedenen Betriebssystemen
DE102014003704B4 (de) Plattform-agnostisches Powermanagement
DE102014002181B4 (de) Chip und Verfahren zum Betreiben eines Chips
DE602004012563T2 (de) Mehrfädiges DMA
DE102015108689A1 (de) Sicherheitsknoten in Zwischenverbindungsdatenbussen
DE112012005700T5 (de) Externe Hilfsausführungseinheiten-Schnittstelle zur ausserhalb des Chips angeordneten Hilfsausführungseinheit
DE3606211A1 (de) Multiprozessor-computersystem
DE112013002090T5 (de) Hochleistungsfähige physikalische Kopplungsstrukturschicht
DE102010054337A1 (de) Mechanismen, um ineffizientes Core-Hopping zu vermeiden und Hardware-unterstützte Auswahl eines Niedrigleitungszustands bereitzustellen
DE102013200503A1 (de) Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik
DE102016122375A1 (de) Dynamischer containerisierter Systemspeicherschutz für Niedrigenergie-MCUs
DE69219848T2 (de) Verfahren zur Behandlung von Datenübertragungen in einen Computersystem mit einem Zweibusbau
DE112018001088T5 (de) Anwendung von framing-regeln für eine hochgeschwindigkeitsdatenverbindung
EP2677425A1 (fr) Dispositif d'accélération avec assistance pour machines virtuelles
DE102015102135A1 (de) Unterbrechbares Exklusivspeichern
DE102016203808A1 (de) Verringern der Bevorrechtigung virtueller Maschinen in einer virtualisierten Umgebung
DE102013209643A1 (de) Mechanismus für optimierte Nachrichtenaustauschdatenübertragung zwischen Nodelets innerhalb eines Plättchens
DE102012017339B4 (de) Rechnersystem
DE102018005759A1 (de) Verbinden von beschleunigerressourcen unter verwendung einesswitches
DE112011100854B4 (de) Schnelle Datenfernübertragung und Fernberechnung zwischen Prozessoren

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15825790

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15825790

Country of ref document: EP

Kind code of ref document: A2