EP2250553A1 - Procede d'execution d'une application informatique, kit et aeronef associes - Google Patents

Procede d'execution d'une application informatique, kit et aeronef associes

Info

Publication number
EP2250553A1
EP2250553A1 EP09718889A EP09718889A EP2250553A1 EP 2250553 A1 EP2250553 A1 EP 2250553A1 EP 09718889 A EP09718889 A EP 09718889A EP 09718889 A EP09718889 A EP 09718889A EP 2250553 A1 EP2250553 A1 EP 2250553A1
Authority
EP
European Patent Office
Prior art keywords
execution
application
removable media
operating system
aircraft
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP09718889A
Other languages
German (de)
English (en)
Inventor
Jean-Philippe Corbefin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
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 Airbus Operations SAS filed Critical Airbus Operations SAS
Publication of EP2250553A1 publication Critical patent/EP2250553A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44584—Portable applications, i.e. making applications self-contained, e.g. U3 standard
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

  • the present invention relates to computer platforms for vehicle control and maintenance functions, and integrated therein. More particularly, the invention relates to a method and system for application execution on such platforms.
  • This computer system or platform typically interacts with vehicle components through servers and with the driver or maintenance operator through screens and input devices. Certain sensitive functions of the vehicle are thus accessible from this platform, for example cruise control or ABS anti-lock braking for the automobile, the automatic piloting and various electronic instruments connected to the GPS for aeronautics.
  • IFE platforms are mentioned in publications such as WO 2007/093327 or EP 1 367 683.
  • the manufacturer guarantees the security of the manufacturer's domain by carrying out the validation and the integration of new equipment and / or computer applications in the platform dedicated to the crew.
  • such a holder may be a rental company, a company owning a fleet of vehicles or even an individual.
  • this holder can in particular be an airline which charters aircraft for the transport of passengers.
  • These personal computers advantageously replace the heavy binder of the historically used pilot and allow the pilot to be itinerant, carrying his mission data and preparing his performance calculations before the flight from his hotel or the pre-boarding room.
  • EFB Electronic Flight Bag
  • TGL36 Temporal Guidance Leaflet of the Joint Aviation Authority JAA and included in Advisory Circular AC No. 120-76A of the FAA Federal Aviation Administration.
  • a class I EFB is composed of a stand-alone portable PC that can be used autonomously, possibly powered by an electrical socket in the aircraft.
  • the display and the control means for example keyboard and mouse, are autonomous.
  • a class II EFB is similar to that of class I, for which a possibility of display and remote controls on cockpit means is proposed in order to be used during all phases of flight. For example, you can use a screen built into the cockpit, a keyboard and a TrackBall cockpit, the PC being connected to these remote interfaces via a docking station. The laptop is not attached to the aircraft which allows the pilot to dispose of it outside the aircraft.
  • This class II EFB allows access to read-only avionics parameters. A great deal of independence between the EFB and the NSS platform is maintained allowing the airline to freely install the software it wants.
  • EFBs are generally chosen by the airlines. They can be changed frequently or even be separate between two pilots operating consecutively on the aircraft. They then have the major disadvantage of requiring a complex integration and installation in the cockpit of the aircraft, for example because it is difficult to have a connector or a docking station generic enough to accommodate all the laptops available on the market.
  • the aircraft manufacturer has no control over these computers in the airliner domain. In fact, these computers may not meet all the security standards applicable to manufacturers, creating security risks associated with running these computers.
  • Class III EFB is equipment that is permanently attached to the aircraft, for example I 1 ILO ("Onboard Information Terminat" according to the English terminology, corresponding to a display and interaction device for the consultation of the aircraft. an electronic version of flight documents such as maintenance manuals) in the Airbus A340 (commercial name) or which forms a part number (identification number in the NSS system), of the manufacturer, for example the EFB in Airbus A380 (commercial name)
  • This class III EFB class also allows access to read-only avionics parameters due to its integration into the system.
  • the invention aims in particular at a method of executing a computer interfacing application with a crew of a vehicle, the method comprising: reading a removable medium, comprising said application to be executed, by means of a removable media player equipping an execution system embedded in the vehicle, the execution of said application by means of execution equipping said execution system and connected to said removable media player, said execution of the application requiring the permanent recording of data necessary for its execution only on said removable media.
  • “permanent” is meant here the storage or the recording of data beyond the execution of the application, that is to say, data that lasts in the memories while the application is no longer in execution.
  • This "permanent” storage is contrasted with “temporary” storage, which generally concerns the storage of data in a random access memory, such as RAM, to enable a microprocessor to efficiently carry out the execution of the application.
  • the invention also relates to a method of executing a computer interfacing application with a crew of a vehicle, said application implementing associated data necessary for its execution, the method comprising: reading a removable medium , comprising said application to be executed, by means of a removable media player equipping an execution system embedded in the vehicle, the execution of said application by execution means equipping said execution system and connected to said reader removable media, said execution of the application being performed without the permanent storage in said execution system, said associated data.
  • This permanent storage targets nonvolatile memories such as the registers of an operating system, any rewritable memory (EEPROM, Flash, ...) or hard disks.
  • the ability to manipulate content data such as mission data that can be stored on the removable media and data attached to the aircraft (such as fault history and repair) that are stored in an on-board memory of the aircraft.
  • content data such as mission data that can be stored on the removable media and data attached to the aircraft (such as fault history and repair) that are stored in an on-board memory of the aircraft.
  • This is understood to mean the crew as opposed to the passengers, that is to say the personnel authorized to intervene and interact with the functional parameters of the vehicle.
  • the crew includes, in particular, the pilot or pilots, the train crew and the maintenance operators.
  • the company frees itself from the portable personal computer by the use of a removable medium that includes all the useful applications for the personnel considered. This avoids any problem related to the integration and installation of laptops with regard to plurality existing interfaces. Removable media follow, indeed, more generic connection standards.
  • removable media is an economic gain compared to that of laptops equipping each stakeholder concerned. Indeed, removable media are traditionally seen as passive devices (without autonomous power supply) and lacking own means of execution. In practice, storage means are generally used.
  • Such removable media is easily used by the pilot from his hotel, using a portable personal computer including an ad hoc media player.
  • the interconnection of the removable media with the embedded execution system also allows its use in any phase of flight, for example via visualization and input interfaces provided in the cockpit.
  • the execution system may take the form of a computer system integrated in the vehicle or for example a type EFB class III equipment attached to the aircraft.
  • the unloading of the application from the removable media is also done without further problems for the embedded system, thanks to the implementation of mechanisms that prevent the application, when it is running, leaving fingerprints or traces on the embedded computing platform .
  • it ensures a strong independence between the personal EFB and the platform, so that the airline can freely deploy, via removable media, the applications it wishes without affecting the security of the embedded system.
  • the data associated with the application for its execution may for example be a driver, a library, a source code, an executable file, a configuration file, a computer registry file. These are saved in the removable media and are not deployed for storage to the runtime system.
  • This independence ensures that the computing platform is not configured for a specific media environment. It can accommodate, via various custom removable media, different execution environments, for example a flight environment assigned to a pilot and a test environment and simulations assigned to a maintenance operator. In addition, the embedded system remains safe because it is not polluted by data specific to a non-resident application.
  • the cockpit or a dedicated avionics bay may present a central processing unit (CPU) card connected to a screen dedicated to the information system, input means (keyboard and / or mouse) or designator dedicated to the information system and the media player accessible in the cockpit so that the pilot or operator can connect the media containing the desired application.
  • CPU central processing unit
  • the driver can connect its removable media in an ad-hoc drive provided on a PC terminal or on a portable personal computer, and thus access the desired applications and mission data from the outside the aircraft.
  • said application is a portable application.
  • a "portable application” is a software operating autonomously in the computer file storing the data of its own, without prior installation on the hard disk of the host computer. It is thus possible to freely use this application and associated personal data without leaving a trace on this host computer.
  • traces or fingerprints are, for example, in the known systems of the state of the art, entries in the register, environment variable changes, installations or updates of shared libraries, temporary file creations, application binaries, and configuration files on the host platform hard disk.
  • the execution system comprises an application launcher arranged to detect portable applications contained in a media connected to said reader, and said portable application is launched from the application launcher.
  • the application launcher can, for example, detect U3 files, Framakey (standards for the development of portable applications) or any equivalent format, and display the corresponding applications for selection by the user.
  • said removable media comprises an operating system, the method comprising, prior to said execution of the application, a boot step ("boof") of said execution system on said operating system, said application being executed in the environment of said removable media operating system.
  • boof boot step
  • the operating system used by the pilot or the operator is not related to the vehicle itself but to the removable media. This solution makes it possible to dispense with certain legal provisions relating to the use of operating system.
  • said execution system comprises an input / output basic system (BIOS) configured to boot ("boot” according to a widespread Anglrios) said execution system from an operating system stored on the removable media connected to said reader.
  • BIOS input / output basic system
  • the direct configuration of the BIOS makes it possible to automate the procedure of launching the execution system and the applications contained in the removable media by simply restarting the execution system of the embedded platform.
  • said execution system comprises a virtual machine executed at startup, said operating system being executed in said virtual machine.
  • said execution system comprises an operating system arranged to be executed in said virtual machine.
  • At least two virtual machines are instantiated from a single hardware (CPU) execution system. so as to provide two distinct environments, for example one related to the aircraft manufacturer and the other related to the airline. This eliminates the use of two CPUs whose cost, consumption and physical and thermal congestion would be greater.
  • said execution means form part of a removable module of said execution system, in particular it can be a removable CPU card.
  • said removable medium is one of the set comprising a USB key, a flash memory, a memory card (SD card, compact flash, etc.), a compact disc, a disc DVD.
  • the removable media is a device devoid of execution means, including CPU. This is in particular a removable storage media.
  • the removable media is also devoid of autonomous power supply, battery type.
  • the invention also relates to a method of executing a computer interfacing application with a crew of a vehicle, the method comprising: - reading a removable medium, comprising a portable application, by means of a reader removable media equipping an execution system embedded in the vehicle, the execution of said portable application by means of execution equipping said execution system and connected to said removable media player.
  • the invention also relates to a method of executing a computer interfacing application with a crew of a vehicle, the method comprising: the reading of a removable media, comprising an operating system and said application to be executed, by means of a removable media player equipping an on-board execution system in the vehicle, the booting of said onboard execution system on said removable media operating system, by means of execution equipping said execution system and connected to said removable media player, the execution of said application in said operating system.
  • the invention also relates to a kit for executing a computer interface application with a crew of a vehicle, the kit comprising: a removable medium comprising said application to be executed, an execution system embedded in the vehicle, comprising a removable media player arranged to receive and read said removable media and, connected to said reader, execution means arranged to execute said application contained in said removable media, said removable media being arranged so that said execution of the application requires the permanent recording of data necessary for its execution only on said removable media.
  • the invention also relates to a kit for executing a computer interfacing application with a crew of a vehicle, said application implementing associated data necessary for its execution, the kit comprising: a removable medium comprising said application to execute, an execution system embedded in the vehicle, comprising a removable media player arranged to receive and read said removable media and, connected to said reader, execution means arranged to execute said application contained in said removable media, said removable media being arranged so that said execution of the application does not require the permanent storage in said execution system, said associated data.
  • one of the kits may include means relating to the process characteristics set forth above.
  • said application can be a portable application.
  • the execution system comprises an application launcher arranged to detect the applications contained in said media when the latter is connected to said reader, for example by plug and play means.
  • an operating system can be provided in said removable media and the execution system is arranged to boot (boote ⁇ on said operating system, for example by parameterizing adapted the BIOS of the runtime system.
  • the execution means form part of a removable module of said execution system.
  • the invention also relates to a kit for executing a computer interfacing application with a crew of a vehicle, the kit comprising: a removable medium comprising a portable application, an on-board execution system comprising: a removable media player arranged to receive and read said removable media and, connected to said reader, execution means arranged to execute said portable application in said removable media.
  • the invention also relates to a kit for executing a computer interfacing application with a crew of a vehicle, the kit comprising: a removable medium comprising an operating system and said application to be executed, a system for embedded implementation in the vehicle, comprising a removable media player arranged to receive and read said removable media and, connected to said reader, execution means arranged to boot said embedded system on said removable media operating system and to execute said application in the operating system.
  • the invention also relates to an aircraft comprising such a kit.
  • the advantages, aims and special features of this kit and this aircraft being similar to those of the method object of the present invention, as succinctly explained above, they are not recalled here.
  • the features and advantages of the present invention will become more apparent upon reading a preferred embodiment illustrated by the accompanying drawings, in which:
  • FIG. 1 represents an example of a system embedded in an aircraft, for the implementation of the invention
  • FIG. 2 schematically illustrates a first embodiment of the invention, for example in the system of FIG. 1;
  • FIG. 3 represents, in the form of a logic diagram, steps of the first embodiment of the method according to the invention
  • FIG. 4 illustrates an example of mobile use of applications in connection with the first embodiment of the invention
  • FIG. 5 illustrates, schematically, a second embodiment of the invention, for example in the system of Figure 1;
  • FIG. 6 represents, as a logic diagram, steps of the second embodiment of the method according to the invention.
  • FIG. 7 illustrates, schematically, a third embodiment of the invention, for example in the system of FIG. 1;
  • FIG. 8 illustrates, schematically, a fourth embodiment of the invention.
  • the present invention relates to the execution of a computer application intended for a crew of a vehicle, here an aircraft 1, during which the connection is made for reading a removable medium, comprising the application to execute, to a removable media player equipping an execution system embedded in the vehicle 1, the execution system comprising execution means.
  • the aircraft 1 presents a cockpit 10 from which the pilots or maintenance agents can access an embedded system 100 of the NSS type ("Network Server System", networked server system) presenting tools and applications for assisting the piloting and operation of the aircraft 1.
  • NSS Network Server System
  • the NSS 100 system comprises a subsystem 110, possibly secure, said manufacturer domain or aircraft manufacturer domain, having a processing unit CPU 111, a volatile memory RAM 112, a hard disk 113, peripherals 114 and display devices and inputs accessible from the cockpit, for example a screen 115 and a keyboard / mouse 116. These equipment are connected by a data bus 117.
  • the subsystem 110 may contain sensitive applications for the safety of the aircraft 1. Consequently, the aircraft manufacturer wishes to isolate this subsystem from any other subsystem where third parties could intervene without appropriate qualification. In an embodiment also envisaged, these sensitive applications can be provided in another subsystem, it highly secure, separated from the subsystem 110 by a unidirectional network diode.
  • the subsystem 110 has the simple feature of being integrated by the manufacturer of the aircraft.
  • the subsystem 110 is indicated in the two cases above, with the specificity that in the second case, the certifications of materials and applications relate mainly to those provided for the highly secure subsystem. .
  • the processor 111 allows the execution of applications stored in the hard disk 113. These applications are certified and then integrated into the subsystem 110 by the manufacturer manufacturer.
  • the NSS 100 system also comprises a second subsystem 120, less secure than the subsystem 110, in that the certification and integration conditions are less strong.
  • This subsystem 120 also comprises, connected by a data bus 127, a processing unit CPU 121 for executing applications, a volatile memory RAM 122, a hard disk 123, 124 devices and display devices and seizures accessible from the cockpit, for example a screen 125 and a keyboard / mouse 126.
  • the screens and keyboard / mouse 115, 116, 125 and 126 can be shared in the same devices with a command to switch from one subsystem to another.
  • the subsystems 110 and 120 are interconnected by a gateway 130, in particular allowing the applications executed on the processor 121 to retrieve parameters and avionics data generated by the secure subsystem 110. This retrieval can be performed by read rights on data files and / or parameters stored, for example, in the hard disk 113 or issued by a device 114.
  • the gateway 130 contributes to the safety of the system by protecting the subsystem 110 by limiting the rights of the applications executed in the subsystem 120, in particular the applications of a removable medium as introduced hereinafter. to access the data of the subsystem 110.
  • the subsystem 120 furthermore has a removable media player 128, here a USB memory stick reader ("Universal Serial Bus").
  • the reader can be seen here as the interface that allows the connection between the removable media and the system to allow reading of the first.
  • programs associated with this interface for example drivers or equivalents
  • Several readers 128 may be provided, in particular to allow the connection of removable media having different interfacing formats, for example USB, Firewire (registered name), etc.
  • This reader 128 is accessible from the cockpit 10 of the pilots.
  • Other readers 128 may be provided in the subsystem 120, for example outside the cockpit so that maintenance agents can connect to said subsystem 120.
  • the processing equipment without interaction with the pilots or other agents, especially the CPU 111, 121, RAMs 112, 122, hard disks 113, 123 and peripherals 114, 124 may be integrated in a dedicated space, for example in an avionics rack 11, outside the cockpit 10. Screens and means Additional capture may be provided outside the cockpit 10 to the attention of, for example, flight crew in the passenger cabin. Also, interfaces for connecting screens and / or input means may be provided in addition to or in place of said screens 115 and input means 116, possibly outside the cockpit, to allow maintenance agents to intervene in the process. NSS 100 system from outside the cockpit 10.
  • a first embodiment of the invention is illustrated by means of a simplified representation of the subsystem 120 to which a USB key 200 of a driver is connected.
  • the USB key 200 of the driver constitutes a memory comprising one or more applications 210, 210 ', etc. which have been developed by the pilot airline to provide them with support tools, such as flight planning or procedure, such as checklists. These applications are interfacing applications with the crew of the aircraft (the pilot, among others).
  • the USB key 200 can thus be connected to the USB reader 128 to allow the execution of the application 210 by the CPU 121.
  • the USB key 200 is thus readable and possibly readable for storing data in its memory.
  • the hard disk 123 of the subsystem 120 includes an operating system OS (Operating System, for example Windows [registered name])
  • OS Operating System, for example Windows [registered name]
  • This application launcher 123-3 is launched by the mechanisms of ready to turn (plug and play) when inserting the USB key 200 in the reader 128.
  • the application launcher 123-3 is configured to detect, in the connected USB key, applications established according to a portable application standard, including U3 and Framakey.
  • the application then displays on screen 125 of the driver or other personnel the list of portable applications detected for selection by said driver or other personnel for the execution of the selected application.
  • the pilot takes possession of the aircraft 1 to perform a flight, it puts, in step 300 under power the embedded system 100 and its components.
  • step 302 subsystem 120 starts with running operating system 123-1.
  • the pilot can conventionally use the applications 123-2 already integrated by the aircraft manufacturer (step 304).
  • step 306 the driver inserts, in the USB 128, the USB key 200 containing all its mission data, including checklists and flight planning. These data were prepared in advance by the pilot, for example at his hotel as explained below. This data is accessible through a portable application 210 developed by the airline for all its pilots.
  • step 308 the subsystem 120 detects, by the plug and play mechanisms, the insertion of the key 200 into the reader 128 and starts the launch application 123-3. The latter 123-3 then scans the memory of the USB key to determine the presence of application files meeting a portable application standard, for example files with u3p extension for the U3 standard.
  • the launcher application 123-3 prepared all the portable applications present in the key 200.
  • step 310 the launcher application 123-3 displays on the screen 125 of the driver the list of detected portable applications 210.
  • step 312 the driver selects, with the mouse 126, the desired application 210 and requests its execution, for example by a single click.
  • the application 210 is then executed by the processor 121 using the RAM 122. However no copy of files or configuration is performed on the hard disk 123.
  • the pilot thus has data for his flight. It can also enter information which is then directly stored in the memory of the key 200, for example after-flight use.
  • the executed application 210 can invoke services of the operating system 123-1 to print, for example, on a peripheral 124 of the subsystem 120.
  • the portable application 210 sees a common print management dialog box already configured with the connected printers and configured with the default printer selected.
  • the driver can access several 123-2 and 123-3 applications at the same time.
  • the driver closes the application
  • the airline can develop its own applications and use them in aircraft without certification and prior integration by the aircraft manufacturer.
  • a driver connects its USB key 200 provided with a portable application to a USB drive (not shown) of the secure subsystem 110.
  • the invention applies in the absence of a 123-3 launcher application, in which case the pilot must access, via the file system ("FileSystem" according to the English terminology), the file of the portable application 210 to request execution.
  • FileSystem the file system
  • FIG. 4 the portable use of the USB key 200 is now illustrated.
  • Advance intervention data transmission data, flight planning, maintenance intervention procedure, for example
  • use data recorded during this operation for later use, for example a flight report .
  • the latter has a portable personal computer 400. This tool allows him to carry out these pre or post-flight treatments in any place, including his hotel or meeting room. pre-boarding.
  • the pilot can connect to a PC terminal (not shown) made available in the pre-boarding room or on a computer of the hotel.
  • This personal computer 400 is conventional, has a screen 402, a keyboard 404, a CPU 406 processor for the execution of applications, a hard disk 408 storing applications and an operating system, RAM (not shown) and a USB port associated with means of reading 410.
  • the operating system embedded on the computer 400 is in particular of the same family, that is to say having a binary compatibility, that the 123-1 integrated in the aircraft 1 by the aircraft manufacturer.
  • the driver then connects his USB key 200 to the port 410 of the computer 400. Either using a launcher application provided on the computer
  • the driver accesses its portable application 210 stored in the key 200.
  • the portable application 210 is thus executed.
  • the driver performs the desired treatments, for example modifies the data, reads them, adds them, and so on.
  • the application 210 is closed. Since it is a portable application, no trace is also left on the computer 400.
  • FIG. 1 A second embodiment of the invention will now be described with reference to FIG.
  • the operating system for the execution of the application 210 is no longer embedded in the subsystem 110 or 120 but in the USB key 200 on which the subsystem 120 begins. (in the sense of the Anglicism "boot”).
  • the other features described above in connection with FIGS. 1 to 4 may apply to this embodiment.
  • FIG. 5 illustrates this second embodiment of the invention with the aid of a simplified representation of the subsystem 120 to which is connected the USB key 200 of a driver.
  • the hard disk 123 does not store any particular data. Nevertheless, it can be expected that an operating system, applications and associated data are stored thereon to start system 100 startup in the absence of USB key 200.
  • the processor 121 (and the motherboard of the subsystem 120 in the broad sense) comprises, in read-only memory, a BIOS (Basic Input Output System) 121-1 which specifies the list and the order of the devices to be consulted for the start-up. of the operating system. This is, for the skilled person, the boot order of the BIOS.
  • the BIOS 121-1 specifies to "boot” initially on the USB drive 128 and failing that, to start on the hard disk 123. It is understood that the system may have several removable media players 128 and that the Corresponding BIOS can respectively indicate each of these drives in a predetermined order before consulting the hard disk 123.
  • the USB key 200 has, in addition to applications 210 and 210 ', possibly but not necessarily portable, an operating system 212 and drivers 214.
  • the operating system 212 is not installed, that is to say whose configuration is not yet associated with a specific hardware layer (or hardware).
  • Drivers 214 are certified in advance by the aircraft manufacturer and provided to airlines with aircraft from this aircraft manufacturer. These drivers 214 are preferably generic in the sense that they allow the operating system 212 to recognize any type of equipment whatever the subsystem 120 and the aircraft 1 used in association with the key 200 of the pilot. Thus, it is possible to use the key 200 on other computers.
  • the aircraft manufacturer provides the drivers for a number of major operating systems as well as for network-accessible services provided by the aircraft manufacturer (print server, avionics parameters access service, KCCU unit [for "Keyboard Cursor Control Unit”])
  • the airline is free to integrate or not these functions on the USB key 200 to allow the pilot to access it.
  • the driver supplies the system 100 and therefore its subsystems 110 and 120, in step 600.
  • step 602 the processor 121 accesses and executes the BIOS 121-1.
  • the system determines, in step 604, if there is an operating system accessible on the USB port 128, that is, if a USB key 200 hosting a system of operation is connected. If not (step 606), the subsystem 120 starts on a next device listed in the BIOS, for example on the operating system of the hard disk 123.
  • step 608 the subsystem 120 loads the operating system 212 into RAM for execution by the processor 121.
  • the initialization of the operating system 212 comprises, in step 610, the loading of the generic drivers 214 present in the key 200.
  • the drivers 214 corresponding to the peripherals and installed hardware components are loaded by mechanisms of plug and play.
  • the operating system 212 discovers the BIOS, the chipset, the CPU, the video card, the other peripherals of the subsystem 120 and loads the useful drivers again. for these different components present.
  • a dedicated application automatically executing lists the applications 210, 210 'present on the USB key 200 and presents them to the pilot at step 612, that is to say the pilot, himself even, through the file system, accesses the application
  • step 614 the pilot selects and starts the execution of the desired application, for example the application of checklists.
  • the use of the application 210 allows the driver to access the data (read and / or write) in the key 200. Once the operation of the application 210 is completed, it is terminated, at step 616 at the execution of said application 210. No trace of this execution is stored permanently in the subsystem 120, in particular on the hard disk 213.
  • the computer 400 is configured in its BIOS in the same way as the subsystem 120 previously mentioned in connection with FIGS. 5 and 6, namely to boot on the USB port 410.
  • the driver is thus able to start its operating system 212 on any PC, portable or not.
  • the pilot finds himself in the same working environment outside the plane and on the plane.
  • the laptop 400 provided by the airline to access the portal and corporate service is used only from the USB key after a reboot when inserting the key 200.
  • the hard disk 408 which contains the Desktop office environment is not used and no trace is left on when using the airplane working environment from USB key 200.
  • This third embodiment is very similar to the second embodiment described above except that the subsystem 120 has a virtualization layer which releases the operating system 212 from hardware constraints, especially with respect to drivers 214.
  • FIG. 7 illustrates this third embodiment of the invention with the aid of a simplified representation of the subsystem 120 to which is connected the USB key 200 of a driver.
  • the hard disk 123 stores a first host operating system 123-4, for example a linux kernel or a linux distribution, a virtual machine 123-5 arranged to be executed in this first operating system 123. 4, a second operating system 123-1, for example the same as that mentioned above in connection with Figure 2, and 123-2 applications executable in the second operating system.
  • a first host operating system 123-4 for example a linux kernel or a linux distribution
  • a virtual machine 123-5 arranged to be executed in this first operating system 123. 4
  • a second operating system 123-1 for example the same as that mentioned above in connection with Figure 2, and 123-2 applications executable in the second operating system.
  • the virtual machine may be VMWare, QEmu or XEN for example.
  • the first operating system 123-4 is executed directly on the specific hardware layer 800 of the aircraft (by the use of appropriate pilots). Then, the 123-5 virtual machine is automatically launched, followed by the "traditional" operating system 123-1 proposing to the pilot the various 123-2 applications.
  • USB key 200 is similar to that described with reference to FIG. 5, except that, because of the 123-5 virtualization layer, the drivers 214 'are not generic to satisfy a maximum of material layers. 800 but are specific to the virtualization layer or 123-5 virtual machine.
  • the boot order in the simulated BIOS at the level of the virtualization layer is specified, indicating the port on which a medium with an operating system, for example a CD-ROM, is presented, and possibly other default ports.
  • a medium with an operating system for example a CD-ROM
  • the USB port is the main boot port to boot on the operating system 212.
  • this third embodiment does not limit the number of operating systems running in parallel on the virtual machine, from the same hardware layer. In particular, no system In addition, multiple drives 128 may be used to boot multiple operating systems.
  • the presence of the 123-5 virtualization layer makes it possible to use the same processor for both the aircraft manufacturer and the airliner domain. The separation between these two domains is then achieved by the instantiation of each of the corresponding operating systems in the virtual machine. It is thus possible to have a single processor in the aircraft.
  • USB key 200 A portable use of the USB key 200 (see Figure 4 also) is also conceivable, in which case the computer 400 will have the same linux kernel and virtual machine means that the subsystem 120 mentioned above in connection with the third embodiment.
  • This variant relies on the use of a removable module of the processor 121, allowing the airline to manage itself the obsolescence of the CPU 121.
  • the aircraft manufacturer provides an empty slot to put a card
  • CPU 121 at the free choice of the airline. The latter can choose the CPU power it needs. It can also decide on its replacement for obsolescence.
  • the airline also has a partial physical freedom on the onboard system 100, 110, 120.
  • the CPU boards 121 used comply with avionic standards, for example covering the electrical and / or thermal envelope, in order to guarantee good availability of the function and good safety.
  • An STC certification (“Supplemental Type Certification" in the English terminology) may be provided for this purpose. Thanks to the invention, the airline can freely develop the applications it wants and use them in its aircraft without requiring the intervention for certification and integration of aircraft manufacturers.
  • a removable media comprising a GPS navigation application can be provided.
  • the driver prepares, on his personal computer at home, his journey and the various crossing points.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention se rapport à un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule (1), par exemple un aéronef, au système correspondant et à un aéronef comprenant ce système. Le procédé comprend, en particulier, la lecture (306, 308, 604) d'un média amovible (200), comprenant ladite application à exécuter, au moyen d'un lecteur (128) de média amovible équipant un système d'exécution embarqué (110, 120) dans le véhicule, l'exécution (312, 614) de ladite application par des moyens d'exécution (111, 121) équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application ne requerrant l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible. A titre d'exemple, on utilise une application portable ou on boote le système d'exécution à partir d'un système d'exploitation installé prévu sur le média amovible.

Description

PROCEDE D'EXECUTION D'UNE APPLICATION INFORMATIQUE, KIT ET AERONEF ASSOCIES
La présente invention se rapporte aux plateformes informatiques destinées aux fonctions de pilotage et de maintenance de véhicules, et intégrées dans ceux-ci. Plus particulièrement, l'invention concerne un procédé et un système pour l'exécution d'application sur de telles plateformes.
Dans divers domaines tels que l'aéronautique ou l'automobile, un grand nombre d'applications d'aide au pilotage et/ou à la maintenance est proposé à l'équipage par le biais d'un système informatique embarqué mis en place par le constructeur du véhicule. Ce système délimite un environnement sur lequel le constructeur a la main mise. On le nomme par la suite "domaine constructeur", et notamment "domaine avionneur" dans le cadre spécifique de l'aviation.
Ce système ou plateforme informatique interagit généralement avec des composants du véhicule au travers de serveurs et avec le pilote ou l'opérateur de maintenance au travers d'écrans et de périphériques de saisie. Certaines fonctions sensibles du véhicule sont ainsi accessibles depuis cette plateforme, par exemple le régulateur de vitesse ou le freinage antiblocage ABS pour l'automobile, le pilotage automatique et différents instruments électroniques de bord reliés au GPS pour l'aéronautique.
On connaît un tel système d'information destiné aux pilotes et opérateurs de maintenance aéronautique sous l'appellation de système de serveur réseau (NSS ou "Network Server System" selon la terminologie anglo- saxonne) conformément à la norme Arinc 763. On trouve mention de telles plateformes aéronautiques dans, par exemple, les publications FR 2 895 793, FR 2 892 092, FR 2 831 871 ou EP 1 160 160.
Force est de constater que des niveaux élevés de sécurité sont requis pour l'intégration et/ou la modification de ces plateformes à destination de l'équipage. Cette sécurité requise oppose cette plateforme dédiée au pilotage et/ou à la maintenance à toute autre plateforme informatique à destination des passagers, notamment une plateforme IFE de divertissement à bord ("In-Flight Entertainment selon la terminologie anglo-saxonne).
De telles plateformes IFE sont mentionnées dans des publications telles que WO 2007/093327 ou EP 1 367 683. En pratique, le constructeur garantit la sécurité du domaine constructeur en réalisant lui-même la validation et l'intégration de nouveaux équipements et/ou d'applications informatiques dans la plateforme dédiée à l'équipage.
Il existe donc une difficulté pour tout détenteur du véhicule souhaitant ajouter librement de nouvelles applications et fonctions à cette plateforme.
On définit ainsi un "domaine utilisateur" délimité par l'environnement dans lequel le détenteur du véhicule peut librement intervenir par l'ajout, la modification d'applications. On distingue donc les "domaine utilisateur" et
"domaine constructeur" par le besoin de sécurité que ce dernier exige, par exemple par la mise en place de procédures de certification parfois coûteuses.
Dans le domaine automobile, un tel détenteur peut être une compagnie de location, une société propriétaire d'une flotte de véhicules ou même un particulier.
Dans le domaine aéronautique, autour duquel la suite de la description est recentrée sans pour autant exclure de l'invention d'autres domaines industriels présentant les mêmes problématiques, ce détenteur peut notamment être une compagnie aérienne qui affrète des aéronefs pour le transport de passagers. On parlera alors de "domaine compagnie" (ou "domaine airliner"). II existe également un autre pré-requis pour un certain nombre d'applications à destination des pilotes et/ou opérateurs de maintenance, qui relève de la possibilité pour ceux-ci de pouvoir disposer de ces applications hors de l'aéronef, afin par exemple de préparer un vol (calculs de performances), une procédure d'intervention ou d'effectuer un rapport post-vol à partir de données enregistrées lors du vol.
Il ressort de la pratique actuelle que les solutions connues s'appuient sur l'utilisation d'ordinateurs personnels portables ("Personal Computer11 ou "PC" selon la terminologie anglo-saxonne) qui peuvent être reliés au réseau NSS de l'aéronef pendant le vol, par l'intermédiaire de stations d'accueil.
Ces ordinateurs personnels remplacent avantageusement le lourd cartable du pilote historiquement utilisé et permettent au pilote d'être itinérant, en transportant ses données de missions et préparant ses calculs de performances avant le vol depuis son hôtel ou la salle de pré-embarquement.
Parmi les applications largement utilisées de façon itinérante, on distingue les outils de calcul de performances, les manuels opérationnels comprenant par exemple les listes de vérification ("check lists" selon la terminologie anglo-saxonne), les manuels de maintenance.
Ces ordinateurs personnels sont connus sous l'appellation de sac de vol électronique (EFB pour "Electronic Flight Bag"), normalisée dans la norme
TGL36 (Temporary Guidance Leaflet) de la Joint Aviation Authority JAA et reprise dans le document Advisory Circular AC N°120-76A de la Fédéral Aviation Administration FAA.
On distingue trois catégories de sacs EFB.
Un EFB de classe I est composé d'un PC portable disponible sur étagère utilisable de manière autonome éventuellement alimenté par une prise de courant dans l'aéronef. L'affichage et le moyen de contrôle, par exemple clavier et souris, sont autonomes.
Une grande indépendance entre le PC (domaine airliner) et le système embarqué NSS (domaine avionneur) est proposée permettant à la compagnie aérienne d'installer librement tout logiciel souhaité sur cet EFB classe I. Néanmoins, un tel EFB classe I n'est pas utilisable lors de certaines phases de vol, comme par exemple le décollage et l'atterrissage. En outre, aucun accès aux paramètres avioniques n'est possible par l'absence d'interfaçage avec la plateforme NSS.
Un EFB de classe II s'apparente à celui de la classe I, pour lequel une possibilité d'affichage et de contrôles déportés sur des moyens cockpit est proposée afin de pouvoir être utilisé lors de toutes les phases de vol. Par exemple, on peut utiliser un écran intégré au cockpit, un clavier et un TrackBall cockpit, le PC étant connecté à ces interfaces déportées par l'intermédiaire d'une station d'accueil. Le PC portable n'est ainsi pas attaché à l'avion ce qui permet au pilote d'en disposer hors de l'aéronef.
Cette classe II d'EFB permet l'accès aux paramètres avioniques en lecture seule. Une grande indépendance entre l'EFB et la plateforme NSS est conservée permettant à la compagnie aérienne d'installer toujours librement les logiciels qu'elle désire.
Ces EFB de classe I et II sont généralement choisis par les compagnies aériennes. Ils peuvent être changés fréquemment voire être distincts entre deux pilotes opérants consécutivement sur l'aéronef. Ils présentent alors l'inconvénient majeur de nécessiter une intégration et une installation complexes dans le cockpit de l'aéronef, par exemple parce qu'il est difficile d'avoir un connecteur ou une station d'accueil suffisamment générique pour accueillir tous les ordinateurs portables disponibles sur le marché. En outre, l'avionneur n'a aucun contrôle sur ces ordinateurs du domaine airliner. De fait, ces ordinateurs peuvent ne pas répondre à toutes les normes de sécurité s'appliquant aux constructeurs, engendrant des risques de sécurité liés à l'exécution de ces ordinateurs.
L'EFB de classe III est un équipement qui est attaché définitivement à l'avion, par exemple I1OIT ("Onboard Information Terminât' selon la terminologie anglo-saxonne, correspondant à un dispositif de visualisation et d'interaction pour la consultation d'une version électronique de documents de vol tels que des manuels de maintenance) dans l'Airbus A340 (nom commercial) ou qui forme un part number (numéro d'identification dans le système NSS), du constructeur, par exemple l'EFB dans l'Airbus A380 (nom commercial). Ce type III d'EFB classe permet également l'accès aux paramètres avioniques en lecture seule du fait de son intégration au système.
Néanmoins, dans le cas de l'EFB classe III, la compagnie aérienne ne peut pas déployer librement de logiciel sur cet EFB sans passer par le constructeur en tant qu'intégrateur.
L'invention vise ainsi à résoudre les inconvénients de l'état de la technique. A cet effet, l'invention vise notamment un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant: la lecture d'un média amovible, comprenant ladite application à exécuter, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, l'exécution de ladite application par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application ne requerrant l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible.
On entend ici par "permanent" le stockage ou l'enregistrement de données au-delà de l'exécution de l'application, c'est-à-dire des données qui perdurent dans les mémoires alors que l'application n'est plus en exécution. On oppose ce stockage "permanent" au stockage "temporaire" qui concerne généralement la mémorisation des données dans une mémoire vive, type RAM, pour permettre à un microprocesseur de mener efficacement l'exécution de l'application.
L'invention vise également un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, ladite application mettant en œuvre des données associées nécessaires à son exécution, le procédé comprenant: la lecture d'un média amovible, comprenant ladite application à exécuter, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, - l'exécution de ladite application par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application étant réalisée sans le stockage permanent, dans ledit système d'exécution, desdites données associées.
Ce stockage permanent vise notamment les mémoires non volatiles telles les registres d'un système d'exploitation, toute mémoire réinscriptible (EEPROM, Flash, ...) ou les disques durs. On distingue les données nécessaires à l'exécution de l'application, par exemple la modification de registres pour que le système d'exploitation puisse procéder à cette exécution, des données utilisées lors de l'exécution, par exemple un fichier de l'utilisateur qui n'a aucun caractère essentiel pour ladite exécution.
Selon l'invention, il résulte qu'aucune donnée d'application n'est enregistrée à long terme dans le système d'exécution embarqué.
On comprend ainsi qu'au regard des données associées à une application et nécessaires pour son exécution, aucune de ces données n'est stockée de façon permanente autre part que sur le média amovible, afin de ne pas polluer le système d'exécution. A titre illustratif et tel que développé ci- après, on envisage les applications portables qui délimitent l'inscription de données nécessaires à son exécution au seul dossier qui les comportent, c'est- à-dire sur le média amovible lorsque ces applications sont prévues sur ce média. Un autre exemple envisagé est la présence d'un système d'exploitation installé sur le média amovible et sur lequel le système d'exécution boote; l'application alors exécutée dans ce système d'exploitation n'implique l'inscription de données nécessaires à son exécution que dans les registres ou autre mémoire non volatile qui sont délimités par l'installation du système d'exploitation, c'est-à-dire le média amovible. On conserve cependant la possibilité de manipuler plus librement des données de contenu telles que des données de mission qui peuvent être stockées sur le média amovible et des données attachées à l'avion (historique des pannes et réparation, par exemple) qui sont alors sauvegardées dans une mémoire embarquée de l'avion. II faut entendre ici l'équipage par opposition aux passagers, c'est-à- dire au personnel ayant l'autorisation d'intervenir et d'interagir avec les paramètres fonctionnels du véhicule. L'équipage regroupe ainsi, notamment, le ou les pilotes, le personnel de bord et les opérateurs de maintenance.
Selon l'invention, la compagnie se libère de l'ordinateur personnel portable par l'utilisation d'un média amovible qui comprend l'ensemble des applications utiles pour le personnel considéré. On évite ainsi tout problème lié à l'intégration et l'installation des ordinateurs portables eu égard à la pluralité d'interfaces existantes. Les médias amovibles suivent, en effet, des normes de connexion plus génériques.
En outre, l'utilisation de médias amovibles constitue un gain économique comparé à celle d'ordinateurs portables équipant chacun des intervenants concernés. En effet, les médias amovibles sont traditionnellement vus comme des dispositifs passifs (sans alimentation autonome) et dépourvus de moyens d'exécution propres. En pratique, on a généralement recours à des moyens de stockage.
Un tel média amovible est aisément utilisable par le pilote depuis son hôtel, à l'aide d'un ordinateur personnel portable comprenant un lecteur de média ad hoc.
L'interconnexion du média amovible avec le système d'exécution embarqué (via le lecteur de média) permet également son utilisation en toute phase de vol, par exemple via des interfaces de visualisation et de saisie prévues dans le cockpit.
Le système d'exécution peut prendre la forme d'un système informatique intégré dans le véhicule ou par exemple un équipement de type EFB classe III attaché à l'avion.
Le déchargement de l'application depuis le média amovible se fait également sans problème ultérieur pour le système embarqué, grâce à la mise en place de mécanismes évitant que l'application, lors de son exécution, laisse des empreintes ou traces sur la plateforme informatique embarquée. Ainsi, on assure une forte indépendance entre l'EFB personnel et la plateforme, de sorte que la compagnie aérienne peut librement déployer, via les médias amovibles, les applications qu'elle souhaite sans affecter la sécurité du système embarqué.
Dans ce contexte, les données associées à l'application pour son exécution peuvent par exemple être un pilote, une bibliothèque, un code source, un fichier exécutable, un fichier de configuration, un fichier de registre informatique. Ces dernières sont enregistrées dans le média amovible et ne sont donc pas déployées pour stockage vers le système d'exécution.
Cette indépendance permet que la plateforme informatique ne soit pas configurée pour un environnement de média spécifique. Elle peut ainsi accueillir, via différents médias amovibles personnalisés, des environnements d'exécution différents, par exemple un environnement de vol attribué à un pilote et un environnement de tests et simulations attribué à un opérateur de maintenance. En outre, le système embarqué reste sûr car non pollué par des données spécifiques à une application non résidente.
En pratique et comme décrit plus loin, le cockpit ou une baie avionique dédiée peut présenter une carte d'unité centrale de traitement (CPU) connectée à un écran dédié au système d'information, des moyens de saisie (clavier et/ou souris) ou désignateur dédié(s) au système d'information et le lecteur de média accessible dans le cockpit pour que le pilote ou l'opérateur puisse y connecter le média contenant l'application souhaitée.
Dans la salle de pré-embarquement, par exemple, le pilote peut connecter son média amovible dans un lecteur ad hoc pourvu sur une borne PC ou sur un ordinateur personnel portable, et ainsi accéder aux applications souhaitées et à des données de mission depuis l'extérieur de l'aéronef.
Dans un mode de réalisation de l'invention, ladite application est une application portable.
Au sens connu, une "application portable" est un logiciel fonctionnant de manière autonome dans le dossier informatique stockant les données qui lui sont propres, sans installation préalable sur le disque dur de l'ordinateur hôte. Il est ainsi possible d'utiliser librement cette application et les données personnelles associées sans laisser de trace sur cet ordinateur hôte.
On évite ainsi soit des dysfonctionnements soit des développements supplémentaires liés au besoin de cohabitation efficace de plusieurs applications laissant chacune des traces ou empreintes pouvant interférer sur l'ordinateur. De par la nature même des applications portables, aucune intégration de celles-ci dans le système d'exécution n'est nécessaire pour l'avionneur. Ce dernier évite un surplus de développement tandis que la compagnie peut, à loisir, ajouter, modifier librement ces applications.
Ces traces ou empreintes sont, par exemple, dans les systèmes connus de l'état de la technique, des entrées en base de registre, des modifications de variables d'environnement, des installations ou mises à jour de librairies partagées, des créations de fichiers temporaires, des copies de binaires applicatifs et de fichiers de configuration sur le disque dur de la plateforme hôte. En particulier, le système d'exécution comprend un lanceur d'applications agencé pour détecter des applications portables contenues dans un média connecté audit lecteur, et ladite application portable est lancée à partir du lanceur d'applications.
A l'aide des mécanismes prêt à tourner ("plug and plaγ' selon la terminologie anglo-saxonne), on obtient ainsi un accès rapide et automatique, pour le pilote ou l'opérateur, à l'application contenue dans le média amovible, dès connexion de ce dernier dans le lecteur.
Le lanceur d'applications peut, par exemple, détecter des fichiers U3, Framakey (normes pour le développement d'applications portables) ou tout format équivalent, et afficher les applications correspondantes pour sélection par l'utilisateur.
Dans un mode de réalisation, ledit média amovible comprend un système d'exploitation, le procédé comprenant, préalablement à ladite exécution de l'application, une étape d'amorçage ("boof selon la terminologie anglo-saxonne) dudit système d'exécution sur ledit système d'exploitation, ladite application étant exécutée dans l'environnement dudit système d'exploitation du média amovible.
Les mécanismes de boot déporté sur le média amovible inséré dans le lecteur permettent d'éviter toute pollution de la plateforme hôte par le système d'exploitation ("Operating System" ou OS selon la terminologie anglo- saxonne) lancé et les applications exécutées dans ce système d'exploitation
Grâce aux dispositions de ce mode de réalisation, le système d'exploitation utilisé par le pilote ou l'opérateur n'est pas lié au véhicule lui- même mais au média amovible. Cette solution permet de s'affranchir de certaines dispositions légales relatives à l'utilisation de système d'exploitation.
Par exemple, il existe des licences applicables à des systèmes d'exploitation qui dépendent du territoire concerné pour l'exécution de ceux-ci. Il arrive ainsi que de tels systèmes d'exploitation ne sont pas introduits directement par le constructeur du véhicule, entraînant une impossibilité pour les acquéreurs d'utiliser des applications développées dans l'environnement de ces systèmes d'exploitation. Aussi, grâce au mode de réalisation ci-dessus, la compagnie aérienne peut choisir elle-même son système d'exploitation.
En particulier, ledit système d'exécution comprend un système de base d'entrée/sortie (BIOS) configuré de sorte à amorcer ("booter" selon un anglicisme largement répandu) ledit système d'exécution à partir d'un système d'exploitation stocké sur le média amovible connecté audit lecteur. La configuration directe du BIOS permet d'automatiser la procédure de lancement du système d'exécution et des applications contenues dans le média amovible par un simple redémarrage du système d'exécution de la plateforme embarquée.
Dans un mode de réalisation, ledit système d'exécution comprend une machine virtuelle exécutée au démarrage, ledit système d'exploitation étant exécuté dans ladite machine virtuelle.
Grâce à ces dispositions, on s'affranchit des contraintes matérielles de la plateforme hôte. Ainsi, on évite l'utilisation de pilotes génériques stockés dans le média amovible qui doivent satisfaire à toutes les configurations matérielles de plateformes hôtes avec lesquelles le média amovible peut être utilisé.
Au lieu de cela, on utilise des pilotes spécifiques à la machine virtuelle prévue sur le système d'exécution, notamment on peut prévoir la même machine virtuelle sur tout ou partie des véhicules/aéronefs construits. Avec ces pilotes spécifiques, on accède à plus de fonctionnalités. Il en résulte une amélioration des performances et des services fournis par le système d'exploitation.
En particulier, on prévoit également que ledit système d'exécution comprend un système d'exploitation agencé pour être exécuté dans ladite machine virtuelle.
Grâce à ces dispositions de virtualisation, on instancie au moins deux ordinateurs virtuels à partir d'un seul système d'exécution (CPU) matériel de sorte à fournir deux environnements distincts, par exemple l'un lié à l'avionneur et l'autre lié à la compagnie aérienne. On s'affranchit ainsi de l'utilisation de deux CPU dont le coût, la consommation et l'encombrement physique et thermique seraient plus importants. Dans un mode de réalisation, lesdits moyens d'exécution forment partie d'un module amovible dudit système d'exécution, en particulier il peut s'agir d'une carte CPU amovible.
Selon cette configuration, il est possible d'adapter et de gérer efficacement l'évolution de la puissance des moyens de traitement/exécution tout au long de la vie du véhicule (plusieurs dizaines d'années pour un aéronef).
On veillera cependant à assurer que cette carte CPU suivent les normes, par exemple ARINC 763, de compatibilité avec le reste de la plateforme hôte.
Selon une caractéristique particulière de l'invention, ledit média amovible est l'un parmi l'ensemble comprenant une clé USB, une mémoire flash, une carte mémoire (SD card, compact flash, ...), un compact disque, un disque DVD.
Selon ces exemples, on voit que le média amovible est un dispositif dépourvu de moyens d'exécution, notamment de CPU. Il s'agit en particulier d'un média amovible de stockage. A des fins d'encombrement minimum, le média amovible est également dépourvu d'alimentation électrique autonome, type batterie.
L'invention vise également un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant: - la lecture d'un média amovible , comprenant une application portable, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, l'exécution de ladite application portable par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible. L'invention vise également un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant: la lecture d'un média amovible, comprenant un système d'exploitation et ladite application à exécuter, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, l'amorçage dudit système d'exécution embarqué sur ledit système d'exploitation du média amovible, par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, l'exécution de ladite application dans ledit système d'exploitation.
L'invention a également trait à un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant: un média amovible comprenant ladite application à exécuter, un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application ne requiert l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible.
L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, ladite application mettant en œuvre des données associées nécessaires à son exécution, le kit comprenant: un média amovible comprenant ladite application à exécuter, un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application ne requiert pas le stockage permanent, dans ledit système d'exécution, desdites données associées.
De façon optionnelle, l'un des kits peut comprendre des moyens se rapportant aux caractéristiques de procédé présentées ci-dessus. Notamment, ladite application peut être une application portable. En particulier, le système d'exécution comprend un lanceur d'application agencé pour détecter les applications contenues dans ledit média lorsque ce dernier est connecté audit lecteur, par exemple par des moyens plug and play. En alternative ou en combinaison à l'application portable, un système d'exploitation peut être prévu dans ledit média amovible et le système d'exécution est agencé pour s'amorcer (booteή sur ledit système d'exploitation, par exemple en paramétrant de façon adaptée le BIOS du système d'exécution.
Selon une caractéristique particulière, les moyens d'exécution forment partie d'un module amovible dudit système d'exécution.
L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant: un média amovible comprenant une application portable, un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application portable dans ledit média amovible.
L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant: - un média amovible comprenant un système d'exploitation et ladite application à exécuter, un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour amorcer ledit système d'exécution embarqué sur ledit système d'exploitation du média amovible et pour exécuter ladite application dans le système d'exploitation. L'invention vise également un aéronef comprenant un tel kit. Les avantages, buts et caractéristiques particulières de ce kit et de cet aéronef étant similaires à ceux du procédé objet de la présente invention, telle que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. Les caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture d'un mode préféré de réalisation illustré par les dessins joints, dans lesquels :
- la figure 1 représente un exemple de système embarqué dans un aéronef, pour la mise en œuvre de l'invention;
- la figure 2 illustre, schématiquement, un premier mode de réalisation de l'invention, par exemple dans le système de la figure 1 ;
- la figure 3 représente, sous forme de logigramme, des étapes du premier mode de réalisation du procédé selon l'invention; - la figure 4 illustre un exemple d'utilisation nomade d'applications en lien avec le premier mode de réalisation de l'invention;
- la figure 5 illustre, schématiquement, un deuxième mode de réalisation de l'invention, par exemple dans le système de la figure 1 ;
- la figure 6 représente, sous forme de logigramme, des étapes du deuxième mode de réalisation du procédé selon l'invention;
- la figure 7 illustre, schématiquement, un troisième mode de réalisation de l'invention, par exemple dans le système de la figure 1 ; et
- la figure 8 illustre, schématiquement, un quatrième mode de réalisation de l'invention. La présente invention a trait à l'exécution d'une application informatique destinée à un équipage d'un véhicule, ici un aéronef 1 , au cours de laquelle on procède à la connexion pour lecture d'un média amovible, comprenant l'application à exécuter, à un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule 1 , ce système d'exécution comprenant des moyens d'exécution.
En référence à la figure 1, l'aéronef 1 présente un cockpit 10 à partir duquel les pilotes ou agents de maintenance peuvent accéder à un système embarqué 100 de type NSS ("Network Server System", système de serveur en réseau) présentant des outils et applications d'aide au pilotage et au fonctionnement de l'aéronef 1.
Le système NSS 100 comprend un sous-système 110, éventuellement sécurisé, dit domaine constructeur ou domaine avionneur, présentant une unité de traitement CPU 111 , une mémoire volatile RAM 112, un disque dur 113, des périphériques 114 et des périphériques de visualisation et saisies accessibles depuis le cockpit, par exemple un écran 115 et un clavier/souris 116. Ces équipements sont reliés par un bus de données 117. Le sous-système 110 peut contenir des applications sensibles pour la sécurité de l'avion 1. Par conséquent, l'avionneur souhaite isoler ce sous- système de tout autre sous-système où des tiers pourraient intervenir sans qualification appropriée. Dans une réalisation également envisagée, ces applications sensibles peuvent être prévues dans un autre sous-système, lui hautement sécurisé, séparé du sous-système 110 par une diode réseau unidirectionnelle. Dans ce cas, le sous-système 110 présente la simple particularité d'être intégré par le constructeur de l'avion. Par soucis de simplicité, on indique uniquement le sous-système 110 dans les deux cas ci- dessus, avec la spécificité que dans le deuxième cas, les certifications de matériels et d'applications portent principalement sur ceux prévus pour le sous- système hautement sécurisé.
Le processeur 111 permet l'exécution d'applications stockées dans le disque dur 113. Ces applications sont certifiées puis intégrées dans le sous- système 110 par l'avionneur constructeur. Le système NSS 100 comprend également un deuxième sous- système 120, moins sécurisé que le sous-système 110, en ce sens que les conditions de certification et d'intégration sont moins fortes.
Ce sous-système 120, ou domaine compagnie ou domaine airliner, comprend également, reliés par un bus de données 127, une unité de traitement CPU 121 pour l'exécution d'applications, une mémoire volatile RAM 122, un disque dur 123, des périphériques 124 et des périphériques de visualisation et saisies accessibles depuis le cockpit, par exemple un écran 125 et un clavier/souris 126.
En vue d'un gain de place, les écrans et clavier/souris 115, 116, 125 et 126 peuvent être mutualisés en de mêmes dispositifs avec une commande permettant de passer d'un sous-système à l'autre. Les sous-systèmes 110 et 120 sont interconnectés par une passerelle 130, permettant notamment aux applications exécutés sur le processeur 121 de récupérer des paramètres et données avioniques générées par le sous système sécurisé 110. Cette récupération peut être réalisée par des droits en lecture sur des fichiers de données et/ou paramètres stockés, par exemple, dans le disque dur 113 ou émis par un périphérique 114.
En particulier, la passerelle 130 contribue à la sûreté du système en assurant la protection du sous-système 110 par la limitation des droits des applications exécutées dans le sous-système 120, notamment les applications d'un média amovible comme introduit ci-après, d'accéder aux données du sous- système 110.
Le sous-système 120 présente en outre un lecteur de média amovible 128, ici un lecteur de clé USB ("Universal Sériai Bus" selon la terminologie anglo-saxonne). Le lecteur peut être vu ici comme l'interface qui permet la connexion entre le média amovible et le système afin de permettre la lecture du premier. Généralement, des programmes associés à cette interface (par exemple des pilotes ou équivalents) assurent cette fonction de lecture. Plusieurs lecteurs 128 peuvent être prévus, notamment pour permettre la connexion de médias amovibles présentant des formats d'interfaçage différents, par exemple USB, Firewire (nom déposé), etc.
Ce lecteur 128 est accessible depuis le cockpit 10 des pilotes. D'autres lecteurs 128 peuvent être prévus dans le sous-système 120, par exemple extérieurs au cockpit afin que des agents de maintenance puissent se connecter audit sous-système 120. Les équipements de traitement sans interaction avec les pilotes ou autres agents, notamment les CPU 111 , 121 , les mémoires vives 112, 122, les disques durs 113, 123 et périphériques 114, 124, peuvent être intégrés dans un espace dédié, par exemple dans une baie informatique avionique 11 , hors du cockpit 10. Des écrans et moyens de saisie supplémentaires peuvent être prévus hors du cockpit 10 à l'attention, par exemple, du personnel navigant en cabine passager. Egalement, des interfaces pour connecter des écrans et/ou moyens de saisie peuvent être prévus en plus ou en lieu et place desdits écrans 115 et moyens de saisie 116, éventuellement hors du cockpit, pour permettre à des agents de maintenance d'intervenir dans le système NSS 100 depuis l'extérieur du cockpit 10.
En référence à la figure 2, on illustre un premier mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connecté une clé USB 200 d'un pilote.
La clé USB 200 du pilote constitue une mémoire comprenant une ou plusieurs applications 210, 210', etc. qui ont été développées par la compagnie aérienne du pilote pour lui proposer des outils d'aide, par exemple de planification de vol ou de procédure, telle que les listes de vérification (checklists). Ces applications sont des applications d'interfaçage avec l'équipage de l'avion (le pilote, entre autres). Les applications 210, 210' sont développées dans un format d'application portable, par exemple U3 (norme Sandisk, nom déposé) ou Framakey (format logiciel libre). Ces applications portables ont la particularité d'être prêtes à l'emploi sur la clé USB 200, c'est-à-dire que leur utilisation se fait de manière sécurisée et sans laisser d'informations personnelles sur les machines hôtes, notamment sur les disques durs, sur lesquelles elles sont exécutées, ici sur le système 100.
On note que ces applications ne modifient pas, pour leur exécution, le système d'exploitation dans lequel elles sont exécutées et qu'en outre, elles sont suffisantes en terme de librairies, c'est-à-dire qu'elles se suffisent des librairies intrinsèques du système d'exploitation, sans requérir l'installation de nouvelles librairies, ce qui constituerait une trace laissée sur la machine hôte.
Le déploiement de ces applications nécessite uniquement la copie du dossier contenant les données associées à l'application, c'est-à-dire le fichier de l'application à proprement parler (au format U3 ou Framakey par exemple), ses librairies, ses fichiers de configuration et ses éventuelles données. Ainsi l'exécution de celles-ci est réalisée directement depuis ce dossier, donc en l'espèce depuis le média amovible dans lequel se situe le dossier.
La clé USB 200 peut ainsi être connectée au lecteur USB 128 pour permettre l'exécution de l'application 210 par le CPU 121. La clé USB 200 est ainsi accessible en lecture et éventuellement en écriture pour stocker des données dans sa mémoire.
Le disque dur 123 du sous-système 120 comprend un système d'exploitation OS (Operating System, par exemple Windows [nom déposé])
123-1 qui est lancé au démarrage du sous-système 120, des applications 123-2 déjà intégrées par l'avionneur (et donc certifiées) et un lanceur d'applications
123-3.
Ce lanceur d'applications 123-3 est lancé par les mécanismes de prêt à tourner (plug and play) lors de l'insertion de la clé USB 200 dans le lecteur 128. Le lanceur d'applications 123-3 est configuré pour détecter, dans la clé USB connectée, les applications établies selon une norme d'application portable, notamment U3 et Framakey.
L'application présente alors à l'écran 125 du pilote ou autre personnel la liste des applications portables détectées pour sélection par ledit pilote ou autre personnel en vue de l'exécution de l'application sélectionnée. En détail, comme illustré par la figure 3, lorsque le pilote prend possession de l'avion 1 pour effectuer un vol, il met, à l'étape 300 sous alimentation le système embarqué 100 et de ses composants.
A l'étape 302, le sous-système 120 démarre par l'exécution du système d'exploitation 123-1. A ce stade, le pilote peut utiliser de façon conventionnelle les applications 123-2 déjà intégrées par l'avionneur (étape 304).
A l'étape 306, le pilote insert, dans le lecteur USB 128, la clé USB 200 contenant toutes ses données de mission, notamment les listes de vérification et la planification de vol. Ces données ont été préparées au préalable par le pilote, par exemple à son hôtel comme expliqué plus loin. Ces données sont accessibles au travers d'une application portable 210 développée par la compagnie aérienne pour tous ses pilotes. A l'étape 308, le sous-système 120 détecte, par les mécanismes plug and play, l'insertion de la clé 200 dans le lecteur 128 et démarre l'application lanceur 123-3. Cette dernière 123-3 scanne alors la mémoire de la clé USB pour déterminer la présence de fichiers d'application répondant à une norme d'application portable, par exemple les fichiers présentant une extension u3p pour la norme U3.
Il peut être prévu de limiter le scannage de la clé USB dans le dossier racine ou dans un dossier spécifique afin de limiter le temps de détection pour des médias de grande capacité. En fin d'étape 308, l'application lanceur 123-3 a dressé l'ensemble des applications portables présentes dans la clé 200.
A l'étape 310, l'application lanceur 123-3 affiche à l'écran 125 du pilote la liste des applications portables 210 détectées.
A l'étape 312, le pilote sélectionne, avec la souris 126, l'application souhaitée 210 et demande son exécution, par exemple par un simple clic.
L'application 210 est alors exécutée par le processeur 121 en utilisant la mémoire vive 122. Cependant aucune copie de fichiers ou configuration n'est effectuée sur le disque dur 123.
Le pilote dispose ainsi des données pour son vol. Il peut également saisir des informations qui sont alors directement enregistrées dans la mémoire de la clé 200, pour une utilisation après vol par exemple.
A titre d'exemple, l'application 210 exécutée peut invoquer des services du système d'exploitation 123-1 pour imprimer, par exemple, sur un périphérique 124 du sous-système 120. En pratique, l'application portable 210 voit apparaître une boite de dialogue commune de gestion des impressions déjà configurée avec les imprimantes connectées et configurée avec l'imprimante par défaut sélectionnée.
Le système d'exploitation étant de préférence multi-tâches, le pilote peut accéder à plusieurs applications 123-2 et 123-3 en même temps. A la fin de l'utilisation de l'application 210, le pilote ferme l'application
210 à l'étape 314. De par la nature des applications portables 210, 210', aucune donnée associée à l'application exécutée ne demeure sur le disque dur du sous-système 120.
Ainsi, grâce à l'invention, la compagnie aérienne peut développer ses propres applications et les utiliser dans les avions sans certification et intégration préalables par l'avionneur.
On note qu'il est également envisageable qu'un pilote connecte sa clé USB 200 munie d'une application portable à un lecteur USB (non représenté) du sous-système sécurisé 110.
Du coup, on peut envisager un unique sous-système 110 sans sortir du contexte de l'invention.
On note également que l'invention s'applique en l'absence d'application lanceur 123-3, auquel cas le pilote doit accéder, au travers du système de fichiers ("FileSystem" selon la terminologie anglo-saxonne), au fichier de l'application portable 210 pour en demander l'exécution. En référence à la figure 4, on illustre maintenant l'utilisation nomade de la clé USB 200. Comme mentionné précédemment, il apparaît utile pour l'utilisateur du véhicule 1 , ici le pilote ou l'agent de maintenance, de pouvoir préparer à l'avance des données d'intervention (données de mission, planning de vol, procédure d'intervention de maintenance, par exemple) et/ou d'utiliser des données enregistrées lors de cette intervention pour une exploitation ultérieure, par exemple un rapport de vol.
En se limitant pour la description uniquement au pilote d'avion, ce dernier dispose d'un ordinateur personnel portable 400. Cet outil lui permet d'effectuer ces traitements pré ou post-vol en tout lieu, notamment à son hôtel ou en salle de pré-embarquement.
A titre d'alternative, le pilote peut se connecter à une borne PC (non représentée) mise à sa disposition dans la salle de pré-embarquement ou sur un ordinateur de l'hôtel.
Cet ordinateur personnel 400 est classique, présente un écran 402, un clavier 404, un processeur CPU 406 pour l'exécution d'applications, un disque dur 408 stockant des applications et un système d'exploitation, de la mémoire vive (non représentée) et un port USB associé à des moyens de lecture 410. Le système d'exploitation embarqué sur l'ordinateur 400 est notamment de même famille, c'est-à-dire présentant une compatibilité binaire, que celui 123-1 intégré dans l'avion 1 par l'avionneur.
Le pilote connecte alors sa clé USB 200 sur le port 410 de l'ordinateur 400. Soit à l'aide d'une application lanceur prévue sur l'ordinateur
400 (et procédant de façon identique à celle expliquée ci-dessus), soit directement au travers du système de fichier embarqué dans l'ordinateur 400, le pilote accède à son application portable 210 stockée dans la clé 200.
L'application portable 210 est ainsi exécutée. Le pilote effectue les traitements souhaités, par exemple modifie les données, les lit, en ajoute, etc.
En fin d'utilisation, l'application 210 est fermée. Puisqu'il s'agit d'une application portable, aucune trace n'est également laissée sur l'ordinateur 400.
On décrit maintenant, en référence à la figure 5, un deuxième mode de réalisation de l'invention. Dans ce deuxième mode de réalisation, le système d'exploitation pour l'exécution de l'application 210 n'est plus embarqué dans le sous-système 110 ou 120 mais dans la clé USB 200 sur laquelle le sous-système 120 s'amorce (au sens de l'anglicisme "booter"). Les autres caractéristiques décrites ci-dessus en lien avec les figures 1 à 4 peuvent s'appliquer à ce mode de réalisation.
Plus en détail, la figure 5 illustre ce deuxième mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connectée la clé USB 200 d'un pilote.
Dans la figure 5, le disque dur 123 ne stocke aucune donnée particulière. Néanmoins, on peut prévoir qu'un système d'exploitation, des applications et données associées sont stockés sur celui-ci pour se lancer au démarrage du système 100 en l'absence de clé USB 200.
Le processeur 121 (et la carte mère du sous-système 120 au sens large) comprend, en mémoire morte, un micrologiciel BIOS (Basic Input Output System) 121-1 qui précise la liste et l'ordre des périphériques à consulter pour le démarrage du système d'exploitation. Il s'agit, pour l'homme du métier, de l'ordre de boot du BIOS. Pour l'invention, le BIOS 121-1 précise de "booter" initialement sur le lecteur USB 128 et à défaut, de démarrer sur le disque dur 123. Il est entendu que le système peut présenter plusieurs lecteurs de médias amovibles 128 et que le BIOS correspondant peut indiquer respectivement chacun de ces lecteurs dans un ordre prédéterminer avant de consulter le disque dur 123.
La clé USB 200 présente, en sus des applications 210 et 210', éventuellement mais non nécessairement portables, un système d'exploitation 212 et des pilotes 214.
Le système d'exploitation 212 est non installé, c'est-à-dire dont la configuration n'est pas encore associée à une couche matérielle (ou hardware) spécifique.
Les pilotes 214 (ou drivers selon la terminologie anglo-saxonne) sont certifiées au préalable par l'avionneur et fournis aux compagnies aériennes disposant d'avions de cet avionneur. Ces pilotes 214 sont de préférence génériques au sens où ils permettent au système d'exploitation 212 de reconnaître tout type de matériel quelque soit le sous-système 120 et l'avion 1 utilisé en association avec la clé 200 du pilote. Ainsi, il est possible d'utiliser la clé 200 sur d'autres ordinateurs.
En pratique, l'avionneur fournit les pilotes pour un certain nombre de systèmes d'exploitation majeurs ainsi que pour des services accessibles en réseau fournis par le domaine avionneur (serveur d'impression, service d'accès aux paramètres avioniques, unité KCCU [pour "Keyboard Cursor Control Unit']). Ainsi la compagnie aérienne est libre d'intégrer ou non ces fonctions sur la clé USB 200 pour permettre au pilote d'y accéder. En référence à la figure 6 qui illustre un exemple d'étapes mises en oeuvre dans ce deuxième mode de réalisation, le pilote alimente le système 100 et donc ses sous-systèmes 110 et 120, à l'étape 600.
A l'étape 602, le processeur 121 accède et exécute le BIOS 121-1. A la première commande du BIOS, le système détermine, à l'étape 604, s'il existe un système d'exploitation accessible sur le port USB 128, c'est- à-dire si une clé USB 200 hébergeant un système d'exploitation est connectée. Dans la négative (étape 606), le sous-système 120 démarre sur un périphérique suivant listé dans le BIOS, par exemple sur le système d'exploitation du disque dur 123.
Dans l'affirmative (étape 608), le sous-système 120 charge le système d'exploitation 212 en mémoire RAM pour son exécution par le processeur 121.
Afin d'adapter le système d'exploitation 212 à la couche matérielle du sous-système 120, l'initialisation du système d'exploitation 212 comprend, à l'étape 610, le chargement des pilotes 214 génériques présents dans la clé 200. Seuls les pilotes 214 correspondants aux périphériques et composants matériels installés sont chargés par des mécanismes de plug and play.
Ainsi, à chaque redémarrage dans un sous-système d'exécution 120, le système d'exploitation 212 découvre le BIOS, le chipset, le CPU, la carte vidéo, les autres périphériques du sous-système 120 et charge à nouveau les pilotes utiles pour ces différents composants présents.
On remarque que l'exécution du système d'exploitation utilise uniquement la mémoire vive 122, le processeur 121 et les éventuels périphériques 124. Aucune donnée n'est écrite sur le disque dur 123. Ainsi, lorsqu'il sera mis fin à l'exécution du système d'exploitation, aucune donnée ne subsistera, ce qui permet l'accueil d'une nouvelle clé USB 200 sans problème d'inter-fonctionnement.
Une fois le système d'exploitation 212 en exécution, soit une application dédiée s'exécutant automatiquement liste les applications 210, 210' présentes sur la clé USB 200 et les présente au pilote lors de l'étape 612, soit le pilote, lui-même, au travers du système de fichiers, accède à l'application
210, 210' de son choix, à l'étape 612.
A l'étape 614, le pilote sélectionne et lance l'exécution de l'application souhaitée, par exemple l'application de listes de vérification.
On note ici que, puisque le système d'exploitation 212 est sur la clé USB 200, les paramètres ou données associées aux applications 210, 210' sont également sur la clé 200. Ainsi, aucune pollution du disque dur 123 n'est réalisée pour l'exécution de ces applications. On peut bien sûr utiliser des applications portables comme exposées ci-dessus, qui garantissent qu'aucune donnée n'est copiée dans un autre fichier.
L'utilisation de l'application 210 permet au pilote d'accéder aux données (lecture et/ou écriture) dans la clé 200. Une fois l'exploitation de l'application 210 terminée, il est mis fin, à l'étape 616, à l'exécution de ladite application 210. Aucune trace de cette exécution n'est stockée de façon permanente dans le sous-système 120, notamment sur le disque dur 213.
En ce qui concerne l'utilisation nomade de la clé 200 par le pilote, l'ordinateur 400 est configuré dans son BIOS de la même façon que le sous- système 120 précédemment évoqué en lien avec les figures 5 et 6, à savoir booter sur le port USB 410. Le pilote est ainsi capable de démarrer son système d'exploitation 212 sur n'importe quel PC, portable ou non.
Ainsi, le pilote se retrouve dans le même environnement de travail hors de l'avion et dans l'avion. Le PC portable 400 que lui fournit la compagnie aérienne pour accéder au portail et service d'entreprise est utilisé uniquement à partir de la clé USB après un redémarrage lors de l'insertion de la clé 200. Ainsi le disque dur 408 qui contient l'environnement bureautique entreprise n'est pas utilisé et aucune trace n'est laissée dessus lors de l'utilisation de l'environnement de travail avion à partir de la clé USB 200.
On note ainsi que le même PC portable 400 présente deux environnements de travail indépendants l'un de l'autre et sans aucune porosité : bureautique entreprise et environnement avion (également appelé Flight Ops - système d'exploitation de vol). On décrit maintenant, en référence aux figures 7 et 8, un troisième mode de réalisation de l'invention.
Ce troisième mode de réalisation est très semblable au deuxième mode de réalisation exposé ci-dessus à ceci près que le sous-système 120 présente une couche de virtualisation qui libère le système d'exploitation 212 de contraintes matérielles, notamment vis-à-vis des pilotes 214.
Les caractéristiques décrites ci-dessus en lien avec les figures 1 à 6 peuvent s'appliquer à ce mode de réalisation. Plus en détail, la figure 7 illustre ce troisième mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connectée la clé USB 200 d'un pilote.
Dans la figure 7, le disque dur 123 stocke un premier système d'exploitation hôte 123-4, par exemple un noyau linux ou une distribution linux, un machine virtuelle 123-5 agencée pour être exécutée dans ce premier système d'exploitation 123-4, un deuxième système d'exploitation 123-1 , par exemple le même que celui évoqué ci-dessus en lien avec la figure 2, et des applications 123-2 exécutables dans le deuxième système d'exploitation. Ces différents composants logiciels sont intégrés par Pavionneur.
La machine virtuelle peut être conforme à VMWare, QEmu ou XEN par exemple.
Comme illustré par la figure 8, au démarrage du sous-système 120, le premier système d'exploitation 123-4 est exécuté directement sur la couche matérielle 800 spécifique de l'avion (par l'utilisation de pilotes adéquats). Ensuite, la machine virtuelle 123-5 est automatiquement lancée, suivie du système d'exploitation "traditionnel" 123-1 proposant au pilote les différentes applications 123-2.
Par ailleurs, la clé USB 200 est similaire à celle décrite en lien avec la figure 5, à ceci près que, du fait de la couche de virtualisation 123-5, les pilotes 214' ne sont pas génériques pour satisfaire un maximum de couches matérielles 800 mais sont spécifiques à la couche de virtualisation ou machine virtuelle 123-5.
En pratique, on précise l'ordre d'amorçage dans le BIOS simulé au niveau de la couche de virtualisation, en indiquant le port sur lequel on présente un médium disposant d'un système d'exploitation, par exemple un CD-ROM, et éventuellement d'autres ports par défaut. Ici, on peut spécifier le port USB comme port principal d'amorçage pour démarrer sur le système d'exploitation 212. On note que ce troisième mode de réalisation ne limite pas le nombre de systèmes d'exploitation exécutés en parallèle sur la machine virtuelle, à partir d'une même couche matérielle. Notamment, aucun système d'exploitation ne peut être prévu dans le disque dur 123. En outre, plusieurs lecteurs 128 peuvent être utilisés pour faire démarrer plusieurs systèmes d'exploitation.
Enfin, la présence de la couche de virtualisation 123-5 permet d'utiliser un même processeur à la fois pour le domaine avionneur et le domaine airliner. La séparation entre ces deux domaines est alors réalisée par l'instanciation de chacun des systèmes d'exploitation correspondant dans la machine virtuelle. Il est ainsi possible d'avoir un seul processeur dans l'avion.
Une utilisation nomade de la clé USB 200 (voir figure 4 également) est également envisageable, auquel cas l'ordinateur 400 disposera des mêmes moyens de noyau linux et de machine virtuelle que le sous-système 120 évoqué ci-dessus en lien avec le troisième mode de réalisation.
On décrit maintenant une variante de chacun des modes de réalisation précédemment décrits, de préférence du deuxième mode de réalisation qui présuppose qu'aucune installation logicielle n'est prévue a priori dans le sous-système 120.
Cette variante repose sur l'utilisation d'un module amovible du processeur 121 , permettant à la compagnie aérienne de gérer elle-même l'obsolescence de la carte CPU 121. Ainsi, l'avionneur fournit un emplacement vide pour mettre une carte
CPU 121 au libre choix de la compagnie aérienne. Cette dernière peut ainsi choisir la puissance de CPU dont elle a besoin. Elle peut aussi décider de son remplacement pour obsolescence.
Ainsi, outre la liberté logicielle obtenue grâce au procédé objet de l'invention, la compagnie aérienne dispose également d'une liberté partielle matérielle sur le système embarqué 100, 110, 120.
Selon une caractéristique favorisant la sécurité du système embarqué 100, les cartes CPU 121 utilisées sont conformes à des standards avioniques, portant par exemple sur l'enveloppe électrique et/ou thermique, afin de garantir une bonne disponibilité de la fonction et une bonne sûreté. Une certification STC ("Supplemental Type Certification" selon la terminologie anglo- saxonne) peut être prévue à cette fin. Grâce à l'invention, la compagnie aérienne peut développer librement les applications qu'elle souhaite et les utiliser dans ses avions sans nécessiter l'intervention, pour certification et intégration, des avionneurs.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.
Notamment, en lien avec le monde automobile tel qu'évoqué précédemment, un média amovible comprenant une application de navigation GPS peut être prévu.
Le conducteur prépare, sur son ordinateur personnel à son domicile, son trajet et les différents points de passage.
En voiture, ce même conducteur connecte sa clé à son ordinateur de bord (système embarqué) qui permet l'exécution de l'application de navigation selon l'un quelconque des modes de réalisation envisagés ci-dessus en lien avec l'aviation. On note que grâce à l'invention, l'exécution de cette application n'altère pas la sécurité du système embarqué automobile et le média amovible avec son application peut être utilisé dans plusieurs voitures.

Claims

REVENDICATIONS
1. Procédé d'exécution d'une application informatique (210, 210') d'interfaçage avec un équipage d'un véhicule (1), caractérisé en ce que le procédé comprend: la lecture (306, 308, 604) d'un média amovible (200), comprenant ladite application à exécuter, au moyen d'un lecteur (128) de média amovible équipant un système d'exécution embarqué (110, 120) dans le véhicule, - l'exécution (312, 614) de ladite application par des moyens d'exécution (111 , 121) équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application ne requerrant l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible.
2. Procédé selon la revendication précédente, dans lequel ladite application est une application portable.
3. Procédé selon la revendication précédente, dans lequel le système d'exécution comprend un lanceur d'applications (123-3) agencé pour détecter des applications portables contenues dans un média connecté audit lecteur, et ladite application portable est lancée à partir du lanceur d'applications.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit média amovible comprend un système d'exploitation (212), le procédé comprenant, préalablement à ladite exécution de l'application, une étape d'amorçage (608) dudit système d'exécution sur ledit système d'exploitation, ladite application étant exécutée dans l'environnement dudit système d'exploitation du média amovible.
5. Procédé selon la revendication précédente, dans lequel ledit système d'exécution comprend un système de base d'entrée/sortie (BIOS) (121-1) configuré de sorte à amorcer ledit système d'exécution à partir d'un système d'exploitation stocké sur le média amovible connecté audit lecteur.
6. Procédé selon la revendication 4 ou 5, dans lequel ledit système d'exécution comprend une machine virtuelle (123-5) exécutée au démarrage, ledit système d'exploitation (212) étant exécuté dans ladite machine virtuelle.
7. Procédé selon la revendication précédente, dans lequel ledit système d'exécution comprend un système d'exploitation (123-1) embarqué agencé pour être exécuté dans ladite machine virtuelle (123-5).
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdits moyens d'exécution forment partie d'un module amovible dudit système d'exécution.
9. Kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule (1), caractérisé en ce que le kit comprend: un média amovible (200) comprenant ladite application à exécuter (210, 210'), un système d'exécution embarqué (110, 120) dans le véhicule, comprenant un lecteur (128) de média amovible agencé pour recevoir et lire ledit média amovible (200) et, reliés audit lecteur, des moyens d'exécution (111,
121) agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application ne requiert l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible.
10. Aéronef (1) comprenant un kit selon la revendication précédente.
EP09718889A 2008-01-11 2009-01-07 Procede d'execution d'une application informatique, kit et aeronef associes Ceased EP2250553A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0850179A FR2926375B1 (fr) 2008-01-11 2008-01-11 Procede d'execution d'une application informatique, kit et aeronef associes
PCT/FR2009/000009 WO2009112663A1 (fr) 2008-01-11 2009-01-07 Procede d'execution d'une application informatique, kit et aeronef associes

Publications (1)

Publication Number Publication Date
EP2250553A1 true EP2250553A1 (fr) 2010-11-17

Family

ID=39682483

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09718889A Ceased EP2250553A1 (fr) 2008-01-11 2009-01-07 Procede d'execution d'une application informatique, kit et aeronef associes

Country Status (6)

Country Link
US (1) US8935306B2 (fr)
EP (1) EP2250553A1 (fr)
JP (1) JP5512544B2 (fr)
CA (1) CA2711368A1 (fr)
FR (1) FR2926375B1 (fr)
WO (1) WO2009112663A1 (fr)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009057568A1 (de) * 2009-12-09 2011-06-16 Lufthansa Technik Ag Line Replaceable Unit für ein Luftfahrzeug
US20110238980A1 (en) * 2010-03-23 2011-09-29 Fujitsu Limited System and methods for remote maintenance in an electronic network with multiple clients
US9141830B2 (en) 2011-07-22 2015-09-22 Aspen Avionics, Inc. Avionics gateway interface, systems and methods
US9571181B2 (en) 2012-03-01 2017-02-14 Honeywell International Inc. Programmable portable electronic device for airborne operational communications
CN103034569B (zh) * 2012-11-23 2016-02-24 中国航空工业集团公司第六三一研究所 通用飞机机载多冗余设备自动识别与配置方法
FR3003366B1 (fr) * 2013-03-12 2015-04-10 Airbus Operations Sas Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef
US9818248B2 (en) * 2013-11-05 2017-11-14 Sunasic Technologies Inc. Compound and securable key
JP6486011B2 (ja) * 2014-03-28 2019-03-20 株式会社デンソーテン 車載装置の検査システム、車載装置の検査用装置、車載装置、および、可搬型の記憶媒体
US9307317B2 (en) 2014-08-29 2016-04-05 Coban Technologies, Inc. Wireless programmable microphone apparatus and system for integrated surveillance system devices
US9225527B1 (en) 2014-08-29 2015-12-29 Coban Technologies, Inc. Hidden plug-in storage drive for data integrity
US10901750B1 (en) * 2015-08-28 2021-01-26 S-Tec Corporation Method for customizing software functionality with a configuration file
US10165171B2 (en) 2016-01-22 2018-12-25 Coban Technologies, Inc. Systems, apparatuses, and methods for controlling audiovisual apparatuses
US10789840B2 (en) 2016-05-09 2020-09-29 Coban Technologies, Inc. Systems, apparatuses and methods for detecting driving behavior and triggering actions based on detected driving behavior
US10152858B2 (en) 2016-05-09 2018-12-11 Coban Technologies, Inc. Systems, apparatuses and methods for triggering actions based on data capture and characterization
US10370102B2 (en) 2016-05-09 2019-08-06 Coban Technologies, Inc. Systems, apparatuses and methods for unmanned aerial vehicle
US10155583B2 (en) * 2016-10-14 2018-12-18 Goodrich Corporation Aircraft control system architecture
DE102017217432A1 (de) * 2017-09-29 2019-04-04 Siemens Mobility GmbH Konzept zum unidirektionalen Übertragen von Daten
US10293955B1 (en) * 2017-10-31 2019-05-21 Honeywell International Inc. System and method for consolidating, ratifying and escalation of uncertified applications notifications
US11258863B1 (en) * 2020-11-06 2022-02-22 Ge Aviation Systems Llc Systems, devices, and methods for establishing multiple electronic flight bag sessions with a flight management computer
US12116136B2 (en) * 2021-11-19 2024-10-15 The Boeing Company Aircraft information systems, aircraft that include the systems, methods of utilizing the systems, and methods of configuring the systems

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6052134A (en) * 1997-12-22 2000-04-18 Compaq Computer Corp. Memory controller and method for dynamic page management
JP4211101B2 (ja) * 1998-11-12 2009-01-21 ソニー株式会社 情報処理装置及び方法並びに記録媒体
US7392541B2 (en) * 2001-05-17 2008-06-24 Vir2Us, Inc. Computer system architecture and method providing operating-system independent virus-, hacker-, and cyber-terror-immune processing environments
JP4256693B2 (ja) * 2003-02-18 2009-04-22 株式会社日立製作所 計算機システム、ｉ／ｏデバイス及びｉ／ｏデバイスの仮想共有方法
TW200304623A (en) * 2003-05-26 2003-10-01 Ene Technology Inc Method and apparatus for booting from a portable memory card
US7376949B2 (en) * 2003-10-01 2008-05-20 Hewlett-Packard Development Company, L.P. Resource allocation and protection in a multi-virtual environment
US7271740B2 (en) * 2003-12-19 2007-09-18 Fischer Mark R System and process for providing improved aircraft operational safety
WO2005089400A2 (fr) * 2004-03-17 2005-09-29 Riverstone Networks, Inc. Gestion d'informations d'etat de processus dans un environnement de systeme d'exploitation
US7712086B2 (en) * 2004-12-15 2010-05-04 Microsoft Corporation Portable applications
US8274518B2 (en) * 2004-12-30 2012-09-25 Microsoft Corporation Systems and methods for virtualizing graphics subsystems
US7412291B2 (en) * 2005-01-12 2008-08-12 Honeywell International Inc. Ground-based software tool for controlling redundancy management switching operations
JP2006285849A (ja) * 2005-04-04 2006-10-19 Xanavi Informatics Corp ナビゲーション装置
US7941522B2 (en) * 2005-07-01 2011-05-10 Microsoft Corporation Application security in an interactive media environment
US8255112B2 (en) * 2005-10-28 2012-08-28 The Boeing Company Remote aircraft maintenance in a networked environment
DE102005055000A1 (de) * 2005-11-18 2007-05-24 Airbus Deutschland Gmbh Modulares Avioniksystem eines Flugzeuges
US7698025B1 (en) * 2006-09-14 2010-04-13 The Boeing Company Integrating communication and surveillance
US8538028B2 (en) * 2006-11-20 2013-09-17 Toposis Corporation System and method for secure electronic communication services
US20080163208A1 (en) * 2006-12-29 2008-07-03 Jeremy Burr Virtual machine creation for removable storage devices
US20080320578A1 (en) * 2007-06-20 2008-12-25 Robert William Knapp Methods and apparatus for dynamic subscription binding

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009112663A1 *

Also Published As

Publication number Publication date
FR2926375B1 (fr) 2010-02-12
JP5512544B2 (ja) 2014-06-04
US8935306B2 (en) 2015-01-13
US20100287545A1 (en) 2010-11-11
WO2009112663A1 (fr) 2009-09-17
FR2926375A1 (fr) 2009-07-17
JP2011510374A (ja) 2011-03-31
CA2711368A1 (fr) 2009-09-17

Similar Documents

Publication Publication Date Title
WO2009112663A1 (fr) Procede d'execution d'une application informatique, kit et aeronef associes
CN1323353C (zh) 信息处理装置及其控制方法
US9928081B2 (en) Customizing program logic for booting a system
US20130167159A1 (en) Vehicle comprising multi-operating system
US8332496B2 (en) Provisioning of operating environments on a server in a networked environment
JP2011510374A5 (fr)
US20100058328A1 (en) Systems and methods for differential software provisioning on virtual machines having different configurations
EP2460071A2 (fr) Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité
WO2003107220A1 (fr) Systemes informatiques en couches et procedes pour environnements non securises
JP2005071347A (ja) 挿入可能ポータブル・オペレーティング・システム・モジュールを製造し、更新するシステムおよび方法
US8171272B1 (en) Critical pre-OS driver verification
FR2960668A1 (fr) Procede et dispositif de configuration incrementale de modules de type ima
CN114461287A (zh) 操作系统启动方法、装置、电子设备和存储介质
FR3091368A1 (fr) PROCEDE DE FABRICATION D’UNE APPLICATION MATERIELLE METIER SPECIFIQUE SECURISEE ET MODULAIRE ET système D’EXPLOITATION ASSOCIE
CN113302599A (zh) 可升级的交通工具计算方法和设备
US8549270B2 (en) Self-restoring on-board information system
FR3003366A1 (fr) Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef
CN106528226A (zh) 操作系统的安装方法及装置
EP3663953B1 (fr) Procédé et dispositif de contrôle d'accès à une ressource partagée entre tâches logicielles exécutées dans un contexte applicatif prédéterminé
FR2908904A1 (fr) Systeme de pilotage d'un aeronef comportant une base de donnees aeronautique.
Tyler XDA Developers' Android Hacker's Toolkit: The Complete Guide to Rooting, ROMs and Theming
Eklund et al. Using architecture for multiple levels of access to an ecosystem platform
Boswell Inside Windows 2000 Server
Panek Windows Operating System Fundamentals
Halsey Startup and Repair Troubleshooting

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100729

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20120227

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20160411