Patent Description:
During systems and software model based design, it can be advantageous to communicate within models in a way that mimics the underlying software architecture that will exist on an aircraft. Because aircraft and other large modular systems require a large number of resources to construct, some manufacturers have turned to software modeling based design to test the function of the different systems within an aircraft before beginning construction. Typically, this model based design simulates the individual systems present on the aircraft but does not use a standardized communications scheme between each system.

The document "<NPL>) discloses the use of MATLAB/ SIMULINK environments to implement Integrated Modular Avionics (IMA) partitions models through an ARINC <NUM> block set for rapid prototyping of avionics functionalities to be carried out on IMA architectures.

According to an aspect of the present invention, there is provided a system as claimed in claim <NUM>.

Embodiments may include that the simulation model comprises a model in the loop (MIL) simulation.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the simulation model comprises a software in the loop (SIL) simulation.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the simulation model comprises a plurality of partitions.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the plurality of partitions comprise function specific modules.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the simulation model extension can be accessed by each of the plurality of partitions.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the plurality of partitions access the simulation model extension by subscribing to the at least one sampling port.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments may include that the plurality of partitions access the simulation model extension by subscribing to the at least one queueing port.

According to another aspect of the present invention, there is provided a method as claimed in claim <NUM>.

Embodiments of the method may include that the simulation model comprises a model in the loop (MIL) simulation.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments of the method may include that the simulation model comprises a software in the loop (SIL) simulation.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments of the method may include that the simulation model comprises a plurality of partitions.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments of the method may include that the plurality of partitions comprise functional specific modules.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments of the method may include that the simulation model extension can be accessed by each of the plurality of partitions.

In addition to one or more of the features described above, or as an alternative to any of the foregoing embodiments, further embodiments of the method may include that the plurality of partitions access the simulation model extension by subscribing to the at least one sampling port.

Referring to <FIG>, there is shown an embodiment of a processing system <NUM> for implementing the teachings herein. In this embodiment, the system <NUM> has one or more central processing units (processors) 21a, 21b, 21c, etc. (collectively or generically referred to as processor(s) <NUM>). In one or more embodiments, each processor <NUM> may include a reduced instruction set computer (RISC) microprocessor. Processors <NUM> are coupled to system memory <NUM> (RAM) and various other components via a system bus <NUM>. Read only memory (ROM) <NUM> is coupled to the system bus <NUM> and may include a basic input/output system (BIOS), which controls certain basic functions of system <NUM>.

<FIG> further depicts an input/output (I/O) adapter <NUM> and a network adapter <NUM> coupled to the system bus <NUM>. I/O adapter <NUM> may be a small computer system interface (SCSI) adapter that communicates with a hard disk <NUM> and/or tape storage drive <NUM> or any other similar component. I/O adapter <NUM>, hard disk <NUM>, and tape storage device <NUM> are collectively referred to herein as mass storage <NUM>. Operating system <NUM> for execution on the processing system <NUM> may be stored in mass storage <NUM>. A network communications adapter <NUM> interconnects bus <NUM> with an outside network <NUM> enabling data processing system <NUM> to communicate with other such systems. A screen (e.g., a display monitor) <NUM> is connected to system bus <NUM> by display adaptor <NUM>, which may include a graphics adapter to improve the performance of graphics intensive applications and a video controller. In one embodiment, adapters <NUM>, <NUM>, and <NUM> may be connected to one or more I/O busses that are connected to system bus <NUM> via an intermediate bus bridge (not shown). Suitable I/O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols, such as the Peripheral Component Interconnect (PCI). Additional input/output devices are shown as connected to system bus <NUM> via user interface adapter <NUM> and display adapter <NUM>. A keyboard <NUM>, mouse <NUM>, and speaker <NUM> all interconnected to bus <NUM> via user interface adapter <NUM>, which may include, for example, a Super I/O chip integrating multiple device adapters into a single integrated circuit.

In exemplary embodiments, the processing system <NUM> includes a graphics processing unit <NUM>. Graphics processing unit <NUM> is a specialized electronic circuit designed to manipulate and alter memory to accelerate the creation of images in a frame buffer intended for output to a display. In general, graphics processing unit <NUM> is very efficient at manipulating computer graphics and image processing and has a highly parallel structure that makes it more effective than general-purpose CPUs for algorithms where processing of large blocks of data is done in parallel. The processing system <NUM> described herein is merely exemplary and not intended to limit the application, uses, and/or technical scope of the present disclosure, which can be embodied in various forms known in the art.

Thus, as configured in <FIG>, the system <NUM> includes processing capability in the form of processors <NUM>, storage capability including system memory <NUM> and mass storage <NUM>, input means such as keyboard <NUM> and mouse <NUM>, and output capability including speaker <NUM> and display <NUM>. In one embodiment, a portion of system memory <NUM> and mass storage <NUM> collectively store an operating system coordinate the functions of the various components shown in <FIG> is merely a non-limiting example presented for illustrative and explanatory purposes.

Turning now to an overview of technologies that are more specifically relevant to aspects of the disclosure, ARINC <NUM> is a software specification for space and time partitioning in safety-critical avionics real-time operating system (RTOS). It allows the hosting of multiple applications of different software criticality levels on the same hardware in the context of an integrated modular avionics architecture. For integrated modular avionics, a common computing platform provides a concurrency of operation where each application partition is allocated a certain number of milliseconds of execution time through a cycle. The modular nature provides for many partitions where, for example, a radio system is assigned to one partition, a fire protection system is assigned to another partition, and a navigation system, for example, is assigned yet another partition. Each partition is allocated a time slice in the operating system. In order to decouple the real-time operating system platform from the application software, the ARINC <NUM> defines an application programming interface (API) called Application Executive (APEX).

Turning now to an overview of the aspects of the disclosure, an ARINC <NUM> APEX API for inter-partition communications using sampling and queueing ports as an extension to a modeling language is provided. An extension is a software component that adds a specific feature to an existing computer program. During systems and software model based design, communicating within models in a way that mimics the underlying software architecture can be advantageous. Embodiments provide fidelity to Model in the Loop (MIL) simulations and Software in the Loop (SIL) simulations. Also, embodiments includes an encoding/decoding of model data signals generated into/from the targeted communications data structures as defined by ARINC <NUM> avionics application software standard interface. In essence, a modeling language extension is provided that mimics the underlying software architecture for ARINC-<NUM> APEX API for inter-partition communications.

Turning now to a more detailed description of aspects of the present invention, <FIG> depicts a software extension <NUM> for inter-partition communications according to one or more embodiments.

The software extension <NUM> sampling port create service request <NUM> given a sampling port name, maximum message size, port direction, and refresh period, will create the underlying data structures necessary to support the other sampling port facilities of the software extension <NUM> as well as assign and return a unique sampling port identifier and a return code containing indication of any errors. This sampling port create service request <NUM> will mimic the ARINC <NUM> CREATE_SAMPLING_PORT service request in the modeled environment.

The software extension <NUM> sampling message encode facility <NUM> given separate model application dependent data signals will combine them into a message reference for subsequent input to the software extension <NUM> sampling message write service request <NUM>.

The software extension <NUM> sampling message write service request <NUM> given a sampling port identifier, message reference, and message length, will write the message to the sampling port as well as return a return code containing indication of any errors. This sampling message write service request <NUM> will mimic the ARINC <NUM> WRITE_SAMPLING_MESSAGE service request in the modeled environment.

The software extension <NUM> sampling message read service request <NUM> given a sampling port identifier and message reference, will read the sampling port message and return the message length, message validity, and a return code containing indication of any errors. This sampling message read service request <NUM> will mimic the ARINC <NUM> READ_SAMPLING_MESSAGE service request in the modeled environment.

The software extension <NUM> sampling message decode facility <NUM> given a model reference obtained from software extension <NUM> sampling message read service request <NUM> will decode a message into separate model application dependent data signals.

The software extension <NUM> sampling port get port identifier service request <NUM> given a sampling port name will return the sampling port identifier and a return code containing indication of any errors. This sampling port get port identifier service request <NUM> will mimic the ARINC <NUM> GET_SAMPLING_PORT_ID service request in the modeled environment.

The software extension <NUM> sampling port get port status service request <NUM> given a sampling port identifier will return the sampling port status and a return code containing indication of any errors. This sampling port get port status service request <NUM> will mimic the ARINC <NUM> GET_SAMPLING_PORT_STATUS service request in the modeled environment.

The software extension <NUM> sampling message encode facility <NUM> and the software extension <NUM> sampling message decode facility <NUM> provide for a method of translation between the model signal data and the software extension <NUM> sampling port write and read service requests.

<FIG> depicts the software extension <NUM> for inter-partition communications according to one or more embodiments.

The software extension <NUM> queueing port create service request <NUM> given a queueing port name, maximum size, message range, port direction, and queuing discipline, will create the underlying data structures necessary to support the other queueing port facilities of the software extension <NUM> as well as assign and return a unique sampling port identifier and a return code containing indication of any errors. This queueing port create service request <NUM> will mimic the ARINC <NUM> CREATE_QUEUING_PORT service request in the modeled environment.

The software extension <NUM> queueing message encode facility <NUM> given separate model application dependent data signals will combine them into a message reference for subsequent input to the software extension <NUM> queueing message send service request <NUM>.

The software extension <NUM> queueing message send service request <NUM> given a queueing port identifier, message reference, message length, and timeout, will send the message to the queueing port as well as return a return code containing indication of any errors. This queueing message send service request <NUM> will mimic the ARINC <NUM> SEND_QUEUING_MESSAGE service request in the modeled environment.

The software extension <NUM> queueing message receive service request <NUM> given a sampling port identifier, message reference, length, and time out, will read the queueing port message and return the a return code containing indication of any errors. This queueing message receive service request <NUM> will mimic the ARINC <NUM> RECEIVE_QUEUING_MESSAGE service request in the modeled environment.

The software extension <NUM> queueing message decode facility <NUM> given a model reference obtained from software extension <NUM> queueing message receive service request <NUM> will decode a message into separate model application dependent data signals.

The software extension <NUM> queueing port get port identifier service request <NUM> given a queueing port name will return the sampling port identifier and a return code containing indication of any errors. This queueing port get port identifier service request <NUM> will mimic the ARINC <NUM> GET_QUEUING_PORT_ID service request in the modeled environment.

The software extension <NUM> queueing port get port status service request <NUM> given a sampling port identifier will return the queueing port status and a return code containing indication of any errors. This queueing port get port status service request <NUM> will mimic the ARINC <NUM> GET_QUEUING_PORT_STATUS service request in the modeled environment.

The software extension <NUM> queueing port clear service request <NUM> given a sampling port identifier will clear the indicated queue and return a return code containing indication of any errors. This queueing port clear service request <NUM> will mimic the ARINC <NUM> CLEAR_QUEUING_PORT service request in the modeled environment.

The software extension <NUM> queueing message encode facility <NUM> and the software extension <NUM> queueing message decode facility <NUM> provide for a method of translation between the model signal data and the software extension <NUM> queuing service requests.

In one or more embodiments, the software extension <NUM> can be implemented on a graphical programming environment such as, for example, SIMULINK™. The definition of a message structure for packing (encoding) and unpacking (decoding) can be implemented as a mask in SIMULINK™, for example. In one or more embodiments, the software extension <NUM> can be implemented using any of the components of the processing system <NUM> found in <FIG>.

In one or more embodiments, the software extension <NUM> provides for a sampling mechanism for a simulation that can mimic the operations of aircraft systems interactions. Current modeling languages only provide for purely discrete signals or an aggregation of discrete signals that in no way mimics the message transmission discipline provided for by ARINC <NUM> between the different parts of the modeled partition. The software extension <NUM> allows the sampling ports to be sent a periodic / synchronous message which mimics the ARINC <NUM> definitions.

In one or more embodiments, the software extension <NUM> provides for a queuing mechanism for a simulation that can mimic the operations of aircraft systems interactions. Current modeling languages only provide for purely discrete signals or an aggregation of discrete signals that in no way mimics the first in first out queuing or priority queuing disciplines provided for by ARINC <NUM> between the different parts of the modeled partitions. The software extension <NUM> allows the queueing ports to be sent a burst of aperiodic / asynchronous messages without any of the messages being lost and the receiving ports are not required to read these messages in real time which mimics the ARINC <NUM> definitions.

In one or more embodiments, the software extension <NUM> can be implemented in a modeling/simulation software for the modeling/simulation of aircraft operations and assist with design of an aircraft. The results of the simulations can be used in manufacturing and design of aircraft components. For example, a simulation result might indicate an airflow issue within an exhaust system of an aircraft. This issue can be addressed by adjusting an airflow in various components in the exhaust system of the aircraft. The simulation results can thus be utilized for design and manufacturing components of the aircraft. Tolerances of some machinery can be adjusted automatically based on the results of the modeling/simulations. These tolerances can be later utilized for manufacturing of aircraft components.

<FIG> depicts a flow diagram of a method for modeling language extension for inter-partition communication according to one or more embodiments. The method <NUM> begins at process step <NUM> by defining, by a modeling language, a simulation model. At block <NUM>, the method <NUM> includes defining a simulation model extension, the simulation model extension including at least one sampling port communication module and at least one queueing port communication module. And at block <NUM>, the method <NUM> includes adding the simulation model extension to the simulation model.

Additional processes may also be included. It should be understood that the processes depicted in <FIG> represent illustrations and that other processes may be added or existing processes may be removed, modified, or rearranged without departing from the scope of the present disclosure.

In one or more embodiments, the queuing discipline can be either one of First In First Out (FIFO) or a Priority based queuing discipline.

Claim 1:
A method for manufacturing an aircraft component, including enabling simulation of interactions among subsystems and between subsystems of a modeled system during design by implementing a modeling language extension for inter-partition communication by a processor (<NUM>) communicatively coupled to a memory (<NUM>), the method comprising:
defining (<NUM>), by a modeling language, a simulation model;
defining (<NUM>) a simulation model extension, the simulation model extension comprising:
at least one sampling port communication module; and
at least one queueing port communication module;
adding (<NUM>) the simulation model extension to the simulation model;
running a simulation using the simulation model extension and the simulation model; and
causing at least one aircraft component of the modeled system to be manufactured based at least in part on one or more results of the simulation;
wherein the at least one aircraft component is manufactured using tolerances of machinery, the tolerances being adjusted automatically based on the results of the simulation; and in that the simulation model extension is configured to mimic inter-partition communication according to the ARINC <NUM> standard within the modeled system.