[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP2067099A2 - Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants - Google Patents

Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants

Info

Publication number
EP2067099A2
EP2067099A2 EP07803445A EP07803445A EP2067099A2 EP 2067099 A2 EP2067099 A2 EP 2067099A2 EP 07803445 A EP07803445 A EP 07803445A EP 07803445 A EP07803445 A EP 07803445A EP 2067099 A2 EP2067099 A2 EP 2067099A2
Authority
EP
European Patent Office
Prior art keywords
client
radiocommunication
task
radio communication
interrupt
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.)
Withdrawn
Application number
EP07803445A
Other languages
German (de)
English (en)
Inventor
Erwan Girard
José LOURENCO
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.)
Sierra Wireless SA
Original Assignee
Wavecom SA
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 Wavecom SA filed Critical Wavecom SA
Publication of EP2067099A2 publication Critical patent/EP2067099A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Definitions

  • the field of the invention is that of radiocommunication systems using interrupts, corresponding to asynchronous events, to ensure the physical synchronization between different radiocommunication devices.
  • Radiocommunication devices also known as radio communication terminals or wireless terminals
  • Radiocommunication devices are any device or means capable of exchanging signals using a radio communication system, for example installed in machines or vehicles ( M2M markets, for "Machine to
  • the field of application of the invention covers any cellular radio technology (GSM, 3G, 4G, DECT, CDMA, Wi-Max ...) or point-to-point (Wif ⁇ , Bluetooth, Zigbee ). More specifically, the invention relates to a management technique of the software architecture of a radio communication circuit, in the case where this software architecture comprises a radio communication software stack supporting the execution capacity of at least one client application, that is to say third-party code by comparison with the code of the main radiocommunication application (fimware) which manages the radiocommunication software stack (GSM stack for example).
  • this software architecture comprises a radio communication software stack supporting the execution capacity of at least one client application, that is to say third-party code by comparison with the code of the main radiocommunication application (fimware) which manages the radiocommunication software stack (GSM stack for example).
  • the radiocommunication circuit is an electronic radiocommunication module intended to be integrated into a radiocommunication device.
  • This is for example a module of the family "WISMO" (registered trademark) of the company WAVECOM (applicant for this patent application).
  • WISMO registered trademark
  • WAVECOM appcant for this patent application.
  • the WAVECOM company has indeed for several years proposed an approach overcoming a number of these disadvantages, consisting in grouping together in a single module (called electronic radio communication module), all or at least most of the functions of a digital radiocommunication device .
  • Such a module is in the form of a single housing, preferably shielded, that the device manufacturers can implement directly, without having to take into account a multitude of components.
  • This module (sometimes called “macro component”) is indeed formed of a grouping of several components on a substrate, so as to be implanted in the form of a single element. It includes the essential components (including a processor, memories, and software) necessary for the operation of a radiocommunication device using radio frequencies. So there are no more complex stages of design design, and validation of it. All you have to do is reserve the necessary space for the module. Such a module makes it possible to easily, quickly and optimally integrate all the components in wireless terminals (mobile phones, modems, or any other device operating a wireless standard).
  • the radiocommunication circuit is not a radiocommunication module in the aforementioned sense but a printed circuit included in a radiocommunication device and on which are directly implanted a set of electronic components whose purpose is to provide the various radiocommunication functions necessary, since the reception of a signal
  • Radiocommunication circuits are known in the prior art for embedding client applications.
  • the radiocommunication circuit is an electronic radiocommunication module.
  • This is for example a module of the family "WISMO” (registered trademark) implementing the concept "Open AT” (registered trademark) of the company WAVECOM (applicant for this patent application). It is clear that these disadvantages can be transposed to the case of the aforementioned application variant.
  • no real time capacity is provided for the client application embedded on the radiocommunication module.
  • the execution of a radio communication software stack (GSM / GPRS stack for example) requires real-time responses to interruptions from the radio part of the platform of this module.
  • radiocommunication (GSM / GPRS platform for example). If the module does not take into account this interruption in a very limited time, it loses synchronization to the network. Therefore, the module is no longer able to make / receive calls, send / receive SMS, USSD ...
  • the radiocommunication module manufacturers (especially those destined for the M2M markets and automotive) therefore do not provide their customers with the ability to ship processes whose real-time execution is critical to the proper functioning of the end product.
  • providers of radiocommunication software stack provide a code that compiles and runs on an associated platform (GSM / GPRS platform for example) makes it possible to make / receive calls. Calls ...
  • GSM / GPRS platform for example
  • These software solution providers thus allow their clients to execute very low level code, which could therefore allow the integration of processes whose execution in real time is critical. But in no case do they guarantee that the radio communication software stack will work properly. In addition, this implies a very great complexity of design of the client application and therefore a very strong expertise in the field of radiocommunications (GSM / GPRS for example).
  • this second alternative technique is difficult to use, especially by customers of M2M markets and even more so of any non-expert person both in the final application area of the global product and in the telecommunications field, in particular GSM / GPRS technologies.
  • This software architecture typically comprises a radio communication software stack (in the example of FIG. 1, a GSM stack) comprising: a GSM Stack IT Handler 1, which provides physical link services and synchronize with the GSM network. It corresponds to the GSM physical layer; a set of tasks 2 specific to the GSM stack ("GSM Stack Tasks L1-L3"), divided into layers (Li a L3), and which provide a control service and logical link ("Logical Link and Control Service"). In the GSM standard, it corresponds to L1 / L2 / L3, RR / LAPD / MM / CCRLC /
  • GSM AT Commands Task a set of tasks 3 related to AT commands
  • IdIe Task a task 4 called "IdIe Task” or "Background task” which executes when no other task requests the CPU resource.
  • This software architecture further comprises a client application 5 (in this example an "Open AT" application), comprising a set of client tasks.
  • this client application 5 is positioned between the set of tasks 3 linked to AT commands and the background task 4.
  • the arrow referenced 6 indicates an indicative reaction time axis (from about 1 ms to 1 ms). at about 10 ms).
  • the arrow referenced 7 indicates a priority level axis (from background task 4, which has the lowest priority, to the radiocommunication interrupt manager 1, which has the highest priority).
  • This software architecture can also be broken down into two domains: an interrupt management domain 8, in which is included the radiocommunication interrupt manager 1; and a task management domain 9, in which all the aforementioned tasks are understood (tasks 2 specific to the GSM stack, tasks 3 linked to AT commands, background task 4 and tasks of the client application 5).
  • an interrupt management domain 8 in which is included the radiocommunication interrupt manager 1
  • a task management domain 9 in which all the aforementioned tasks are understood (tasks 2 specific to the GSM stack, tasks 3 linked to AT commands, background task 4 and tasks of the client application 5).
  • a processor internal to the module 24 executes a main radiocommunication application 24 which manages the radio communication software stack (GSM stack for example).
  • GSM stack radio communication software stack
  • microcontroller 22 For example a microcontroller and an additional memory 23, which are external to the radiocommunication module 24 and allow to execute client processes whose real time execution is critical.
  • the microcontroller 22 is connected to a connector 26 of external devices, via I / O interfaces of various uses (GPIOs) 27, Serial interfaces of the SPI (Serial Peripheral Interface) type.
  • GPIOs GPIOs
  • SPI Serial Peripheral Interface
  • SPI1, SPI2 28 and 29, a USB interface 210 and a link carrying interrupts (IT) 211.
  • the invention in at least one embodiment, is intended in particular to overcome these various disadvantages of the state of the art.
  • one of the objectives of the present invention in at least one embodiment, is to provide a technique for managing the software architecture of a radio communication circuit, making it possible to execute a client application foreign to the radiocommunication stack, at a very high priority (which allows to execute processes whose real-time execution is critical), while ensuring the proper functioning of this radiocommunication stack.
  • the invention also aims, in at least one embodiment, to provide such a technique, which is simple to implement and inexpensive.
  • Another object of the invention in at least one embodiment, is to provide such a technique, which makes it possible to dispense with the need to use an additional processor and a supplementary memory, external to the radiocommunication circuit.
  • An additional objective of the invention in at least one embodiment, is to provide such a technique, which can be implemented regardless of the amount of processing involved in the execution of the client application.
  • a method for managing the software architecture of a radio communication circuit comprising a radio communication software stack and at least one client application, said radio communication software stack comprising a radio communication interrupt manager and at least one radiocommunication task, said client application comprising at least one client task.
  • the method comprises a step of interleaving, within said radio communication software stack, at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first level client interrupt manager a higher execution priority than said at least one radiocommunication task and less than said radiocommunication interrupt manager; a second execution priority level client interrupt handler higher than said at least one radio communication task and higher than said radio communication interrupt handler.
  • the general principle of the invention therefore consists in defining a new software architecture, by adding within the radiocommunication stack at least one client interrupt manager, having a level of execution priority that is lower or higher than that of the manager of the client. radiocommunication interruptions, and higher than that of radiocommunication tasks.
  • client interrupt manager client application developers (intended to be executed by the circuit) are offered access to low-level hardware resources in order to respect the first critical time constraints (for example a reaction time of less than 1 ms).
  • the client application comprises at least two subsets of client task (s), each of which comprises at least one client task.
  • the method comprises a step of managing said at least two subsets of client task (s) allowing, within said radio communication software stack, to separate said at least two subsets of client task (s) by at least one radiocommunication task.
  • some client tasks have a higher execution priority level than others, which allows these client tasks to be executed in the same way.
  • second critical time constraints for example a reaction time of between 1 ms and 10 ms, less than the aforementioned first ones.
  • At least one of said subsets of client task (s) comprises a particular client task forming a third client interrupt manager receiving at least one interrupt via at least one of said first and second interrupt handlers.
  • a client application may include several client interrupt handlers, having different levels of execution priority and interposed, within the radio communication stack, between different radio communication tasks.
  • These client interrupt handlers are cascaded, sending out interrupts (in the decreasing direction of the execution priority levels).
  • said client interrupts belong to the group comprising: client interrupts external to said radiocommunication circuit; and client interrupts internal to said radio communication circuit, including interrupts from a clock register included in said radio communication circuit.
  • the maximum execution time of at least one critical process necessary for the design of at least one of said first and second client interrupt managers and / or at least one of said client tasks is predetermined.
  • the method comprises a step of controlling the execution time of at least one of said first and second client interrupt managers and / or at least one of said client tasks, to ensure that the said duration of execution does not exceed a specified maximum duration.
  • said circuit is an electronic radiocommunication module intended to be integrated into a radiocommunication device.
  • the invention in another embodiment, relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor.
  • This computer program product includes program code instructions for performing the steps of the aforesaid method, when said program is run on a computer.
  • the invention relates to a radio communication circuit comprising means for managing a software architecture comprising a radio communication software stack and at least one application.
  • client said radio communication software stack comprising a radiocommunication interrupt manager and at least one radiocommunication task
  • said client application comprising at least one client task.
  • the circuit comprises means for interleaving, within said radio communication software stack, at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first level client interrupt manager a higher execution priority than said at least one radiocommunication task and less than said radiocommunication interrupt manager; a second execution priority level client interrupt manager higher than said at least one radiocommunication task and higher than said radiocommunication interrupt manager.
  • the aforementioned various interleaving means are, for example, software elements resulting from the execution, by a processor included in the circuit, of a main radiocommunication application (generally called "fimware").
  • the circuit according to the invention comprises means for implementing the management method of the software architecture, as described previously (in any one of its various embodiments). 5.
  • FIG. 1 shows a known software architecture, of a GSM stack supporting the Execution capacity of a client application, without real time capacity for this client application;
  • FIG. 2 shows a radiocommunication device according to the prior art, comprising a radiocommunication module having a software architecture according to FIG. 1;
  • FIGS. 1 shows a known software architecture, of a GSM stack supporting the Execution capacity of a client application, without real time capacity for this client application;
  • FIG. 2 shows a radiocommunication device according to the prior art, comprising a radiocommunication module having a software architecture according to FIG. 1;
  • FIG. 3A, 3B, and 3C each have a software architecture according to a first, a second and a third particular embodiment of the invention respectively, of a GSM stack supporting the execution capacity of a client application, with real-time capacity for this client application;
  • FIG. 4 shows a particular embodiment of a radiocommunication device according to the invention, comprising a radiocommunication module having a software architecture according to any one of FIGS. 3A, 3B or 3C; and
  • FIG. 5A illustrates an example of use of the exemplary software architecture according to the invention of FIG. 3A;
  • FIG. 5B illustrates an example of use of the example of software architecture according to the invention of FIG. 3B. 6.
  • FIGS 1 and 2 relate to the prior art and have already been described above.
  • a software architecture according to a first particular embodiment of the invention is now presented, of a GSM stack supporting the execution capacity of a client application, with real time capacity for this purpose. client application.
  • the invention consists in providing the users of the "OPEN AT" environment with the ability to execute foreign code to the GSM / GPRS stack (that is to say a client application). on a GSM / GPRS hardware platform, at a very high priority (which allows real-time execution of critical processes), while ensuring the proper functioning of the GSM / GPRS stack in different aforementioned modes.
  • the concept "OPEN AT” is such that, in addition to the main radiocommunication application which manages a radio communication software stack (GSM stack for example), a radiocommunication module (for example of the "WISMO" family) runs at least one client application.
  • the software architecture comprises a GSM stack and a client application.
  • the GSM stack is conventional and identical to that already described above in relation with FIG. 1. It thus comprises a radio communication interrupt manager 1 ("GSM Stack IT Handler"), a set of tasks 2 specific to the stack. GSM (“GSM Stack Tasks L1-L3”), a set of tasks 3 related to AT commands (“GSM AT Commands Task”) and a background task 4.
  • GSM Stack IT Handler a radio communication interrupt manager 1
  • GSM Stack Tasks L1-L3 a set of tasks 3 related to AT commands
  • GSM AT Commands Task a background task 4.
  • the client application of FIG. 3 differs from that of FIG. 1 in that it is not a monoblock but comprises: a first client interrupt manager (Open AT IT Handler No. 1)
  • this architecture enables the client to execute code at the first and second client interrupt managers referenced 31 and 32.
  • Execution of the code implemented in these first and second client interrupt handlers is triggered by an interrupt, which may be external to the module, or internal for the hardware timer.
  • an interrupt which may be external to the module, or internal for the hardware timer.
  • This allows the execution real-time asynchronous processes.
  • the advantage of this solution is the inter-correlation between on the one hand taking into account the real-time needs of the GSM stack to remain synchronized to the network and on the other hand real-time execution needs of any what kind of client processing (which can be very heavy), without jeopardizing this synchronization to the network.
  • the maximum execution time of the critical processes necessary for designing the code to be executed at the first and second client interrupt handlers 31, 32 and client tasks 33 is predetermined. For example: - the duration of non-interruptibility (interrupt latency);
  • FIG. 3B A software architecture according to a second particular embodiment of the invention, a GSM stack supporting the execution capacity of a client application, with real-time capacity for this application, is now presented in connection with FIG. 3B. customer.
  • the client application of the second particular embodiment comprises: a first client interrupt manager (Open AT IT Handler No. 1) 310, managed so as to have a higher priority level of execution than the radiocommunication interrupt manager 1; a particular client task forming a second client interrupt handler (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack and the set of tasks 3 related to AT commands; and a set of client tasks ("Open AT Tasks Application Tl ... T5), managed to be interposed between the set of tasks 3 related to commands
  • the software architecture according to this second particular embodiment differs from that according to the first particular embodiment of FIG. 3A in that the first client interrupt manager (Open AT IT Handler No. 1) 31 has a higher priority level than the radio interrupt handler 1.
  • GSM / GPRS (ie a client application) on a hardware platform
  • GSM / GPRS at a higher priority level than the GSM / GPRS stack (which allows real-time execution of critical processes), while ensuring the proper functioning of the GSM / GPRS stack in the various modes mentioned above.
  • FIG. 3C shows a software architecture according to a third particular embodiment of the invention, a GSM stack supporting the execution capacity of a client application, with real time capacity for this application. customer.
  • the software architecture according to this third particular embodiment integrates a first 320 and a second 330 client interrupt managers each having a higher priority level of execution than the set of tasks 2 specific to the GSM stack.
  • the client application of FIG. 3C comprises: a first client interrupt manager (Open AT IT Handler No. 3) 330 managed to have a higher priority level of execution than the radio interrupt handler 1; a second client interrupt manager (Open AT IT Handler No. 1) 320, managed to be interposed between the radio communication interrupt manager 1 and the set of tasks 2 specific to the GSM stack; a particular client task forming a third client interrupt manager (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack and the set of tasks 3 related to AT commands; and a set of client tasks ("Open AT Tasks Application Tl ... T5), managed to be interposed between the set of tasks 3 related to AT commands and the background task 4.
  • a first client interrupt manager Open AT IT Handler No. 3
  • a second client interrupt manager Open AT IT Handler No. 1
  • a particular client task forming a third client interrupt manager (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack
  • a user can use the first client interrupt handler (Open AT IT Handler # 3) 330 and the second client interrupt handler (Open AT IT Handler # 1) 320, following the Interrupt response time sought.
  • the user wishes to obtain a response time of less than 20 ⁇ s, he will be able to integrate the code of the client application into the first client interrupt manager 330, and if he is satisfied with response time by ims example (other values can also be envisaged, for example 600 ⁇ s), it can have the code of the client application in the second client interrupt manager 320.
  • a radiocommunication module 44 having a software architecture according to any one of FIGS. 3A, 3B or 3C, obtained by execution by a processor (not represented) of: a main radiocommunication application 42 which manages the radio communication software stack (GSM stack for example) and allows the implementation of the method of the invention, to obtain the software architecture of the invention (in which the client application is distributed within of the pile); and a client application 45 whose different parts are distributed within the GSM stack, as detailed above in relation to any one of FIGS. 3A, 3B or 3C.
  • a main radiocommunication application 42 which manages the radio communication software stack (GSM stack for example) and allows the implementation of the method of the invention, to obtain the software architecture of the invention (in which the client application is distributed within of the pile); and a client application 45 whose different parts are distributed within the GSM stack, as detailed above in relation to any one of FIGS. 3A, 3B or 3C.
  • the radiocommunication module 44 is connected to a connector 26 of external devices, via the same interfaces and links as those already described in Figure 2 (between the same connector 26 and the external microcontroller 22).
  • FIG. 5A An example of use of the software architecture example according to the invention of FIG. 3A is now presented in relation to FIG. 5A.
  • This example relates to: the acquisition of a current value by a sensor in a limited and bounded time, time after which the value raised by the sensor has no value (for example 2 ms); the sensor positioning an interruption at the precise moment when the value is available. this value (measurement) is acquired for the calculation of the instantaneous consumption, the average over several days and storage of the result in memory asynchronously. these computation and storage operations will have to be done at each interruption positioned by the sensor and this independently of the GSM modes in which the module is. weekly, the complete system sends by GPRS the complete measurement report (including for example several hundreds of one-off measurements).
  • this task (Open AT Application Tasks Tl) will look at the defined location of the report. complete which has been acquired, formatted and stored by the second interrupt handler following the instantaneous measurements acquired in a limited time by the first interrupt handler. 8. Once the report is acquired, the Open AT client task initiates a connection
  • steps 7 and 8 are synchronous (they are repeated in a predictive way: every week, once a week) and do not require no real-time case since receiving the report on a weekly basis by the client infrastructure within plus or minus 2 minutes makes absolutely no difference to the quality of the report and its subsequent operation. Thus these actions are executed by the low priority task (Open AT Application Tasks Tl). Conversely, the quality of the report depends on the quality of the instantaneous measurements which are valid only if acquired in less than 2 ms. Here we need guaranteed response time. This is why measurements are acquired by the first interrupt handler (Open AT IT Handler # 1).
  • Step 3 processing the customer interrupt "EXT ITl" will only start when the interrupt coming from the radio part (“GSM IT") will be processed, or this step 3 will be interrupted by the processing of this interruption .
  • This ensures that synchronization with the network is maintained regardless of the asynchronous processing to be performed in real time by the client application.
  • the manufacturer of the module guarantees the maximum time required to allocate a storage area in volatile memory regardless of the GSM status of the module. This ensures that the measurement can be stored less than 2ms after the triggering of the interruption notifying the need for the acquisition of this measurement.
  • Step 4 processing of the "EXT IT2" client interrupt
  • Step 4 processing of the "EXT IT2" client interrupt
  • a check process ensures that the client code in each of the first and second client interrupt handlers (Open AT IT).
  • Handler # 1 and 2) does not run for too long.
  • the software architecture ensures that the processing of an interrupt from the radio portion of the module does not last more than lms; detecting and processing a first "EXT IT 1" client interrupt 52 from the first client interrupt handler ("Open AT IT Handler # 1") 310, a time elapsed between the end of the processing of the client first "GSM IT" interruption 51 and the detection of the first "EXT IT 1" client interrupt 52; detecting and processing a second "GSM IT" radiocommunication interruption 53 from the radiocommunication interrupt manager 1; detection and processing of a second "EXT IT 1" client interrupt 54 from the first client interrupt handler 310.
  • the processing of the second "GSM IT" radiocommunication interrupt 53 is suspended in favor of the processing of the second interruption customer "EXT IT 1" 54 more priority.
  • the processing of the second client interrupt "EXT IT 1" 54 is completed, the processing of the second radiocommunication interruption
  • GSM IT 53 resumes its term; detecting and processing a third "EXT IT 1" client interrupt 55 from the first client interrupt handler 310.
  • a third "GSM IT” radiocommunication interruption 56 is detected.
  • the processing of this third "GSM IT" radio interrupt 56 will not begin until the processing of the third customer interrupt "EXT IT 1" 55 is completed. Thus, it may happen that certain radiocommunication interruptions from the radiocommunication interrupt manager 1 are shifted in time in favor of client interrupts from the first priority client interrupt manager 310.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, cette architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client. La pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication (1) et au moins une tâche de radiocommunication (2 à 4). L'application client comprenant au moins une tâche client. Le procédé comprend une étape d'intercalage, au sein de la pile logicielle de radiocommunication, d'au moins un gestionnaire d'interruptions client, compris dans l'application client, et appartenant au groupe comprenant : un premier gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et moins élevé que le gestionnaire d'interruptions de radiocommunication (1); et un second gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et plus élevé que ledit gestionnaire d'interruptions de radiocommunication (1).

Description

Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants. 1. DOMAINE DE L'INVENTION
Le domaine de l'invention est celui des systèmes de radiocommunication utilisant des interruptions, correspondant à des événement asynchrones, pour assurer la synchronisation physique entre différents dispositifs de radiocommunication.
Par dispositifs de radiocommunication (aussi appelés terminaux de radiocommunication ou terminaux sans-fil), on entend tous dispositifs ou moyens capables d'échanger des signaux à l'aide d'un système de radiocommunication, implantés par exemple dans des machines ou des véhicules (marchés M2M, pour « Machine to
Machine », et automobile).
Le domaine d'application de l'invention couvre toute technologie de radiocommunication cellulaire (GSM, 3G, 4G, DECT, CDMA, Wi-Max...) ou point à point (Wifï, Bluetooth, Zigbee...). Plus précisément, l'invention concerne une technique de gestion de l'architecture logicielle d'un circuit de radiocommunication, dans le cas où cette architecture logicielle comprend une pile logicielle de radiocommunication supportant la capacité d'exécution d'au moins une application client, c'est-à-dire du code tierce par comparaison avec le code de l'application principale de radiocommunication (fïrmware) qui gère la pile logicielle de radiocommunication (pile GSM par exemple).
L'invention s'applique notamment, mais non exclusivement, dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Il s'agit par exemple d'un module de la famille « WISMO » (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet). La société WAVECOM a en effet depuis plusieurs années proposé une approche palliant un certain nombre de ces inconvénients, consistant à regrouper dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de radiocommunication numérique. Un tel module se présente sous la forme d'un boîtier unique, préférentiellement blindé, que les fabricants de dispositifs peuvent implanter directement, sans devoir prendre en compte une multitude de composants. Ce module (encore appelé parfois « macro composant ») est en effet formé d'un regroupement de plusieurs composants sur un substrat, de façon à être implanté sous la forme d'un unique élément. Il comprend les composants (notamment un processeur, des mémoires, et des logiciels) essentiels nécessaires au fonctionnement d'un dispositif de radiocommunication utilisant des fréquences radio électriques. Il n'y a donc plus d'étapes complexes de conception du design, et de validation de celui-ci. Il suffit de réserver la place nécessaire au module. Un tel module permet donc d'intégrer facilement, rapidement et de façon optimisée l'ensemble des composants dans des terminaux sans- fil (téléphones portables, modems, ou tout autre dispositif exploitant un standard sans fil).
Dans une variante d'application de l'invention, le circuit de radiocommunication n'est pas un module de radiocommunication au sens précité mais un circuit imprimé compris dans un dispositif de radiocommunication et sur lequel sont directement implantés un ensemble de composants électroniques ayant pour but d'assurer les différentes fonctions de radiocommunication nécessaires, depuis la réception d'un signal
RF jusqu'à la génération d'un signal audible (dans le cas d'un radio-téléphone), et inversement. 2. ART ANTÉRIEUR
On connaît dans l'art antérieur des circuits de radiocommunication permettant d'embarquer des applications client.
A titre uniquement illustratif, les inconvénients de l'art antérieur sont présentés ci-après dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication. Il s'agit par exemple d'un module de la famille « WISMO » (marque déposée) mettant en œuvre le concept « Open AT » (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet). Il est clair que ces inconvénients peuvent être transposés au cas de la variante d'application précitée.
Selon une première technique connue, aucune capacité temps réel n'est fournie pour l'application client embarquée sur le module de radiocommunication. En effet, dans un module de radiocommunication, l'exécution d'une pile logicielle de radiocommunication (pile GSM/GPRS par exemple) nécessite des réponses temps réel à des interruptions en provenance de la partie radio de la plateforme de ce module de radiocommunication (plateforme GSM/GPRS par exemple). Si le module ne prend pas en compte cette interruption en un temps très limité, il perd la synchronisation au réseau. De ce fait, le module n'est plus capable de passer / recevoir de appels, envoyer / recevoir des SMS, USSD... Pour mémoire, et dans le cas particulier d'une pile GSM/GPRS, il est impératif de garantir le bon fonctionnement de celle-ci dans les modes suivants : déconnecté : le module n'est pas connecté au réseau GSM/GPRS et donc ne peut pas passer de communication ; repos (IDLE) : le module est connecté au réseau GSM/GPRS. Il est donc dans la capacité de recevoir, passer des appels, envoyer/recevoir des SMS, initier une connexion GPRS mais n'utilise aucune de ces possibilités ; connecté : le module passe/reçoit un appel ; envoi/réception de SMS / USSD ; transfert GPRS : le module envoie/reçoit des données sur le lien GPRS ; - recherche de réseau : le module a perdu la synchronisation avec le réseau
(démarrage / hors couverture....) mais est en recherche de réseau sur lequel se synchroniser.
Ne sachant pas quel impact l'exécution des processus des applications client aura sur le bon fonctionnement de leur propre pile logicielle de radiocommunication et donc sur le bon fonctionnement global de leur produit, les fabricants de module de radiocommunication (notamment ceux à destination des marchés M2M et automobile) ne fournissent donc pas à leurs clients la capacité d'embarquer des processus dont l'exécution en temps réel est critique pour le bon fonctionnement du produit final.
Selon une seconde technique connue, les fournisseurs de pile logicielle de radiocommunication (pile GSM/GPRS/EDGE/3G par exemple) fournissent un code qui compilé et exécuté sur une plateforme associée (plateforme GSM/GPRS par exemple) permet de passer/recevoir des appels... Ces fournisseurs de solution logicielle permettent ainsi à leurs clients d'exécuter du code à très bas niveau, code qui pourrait donc permettre d'intégrer des processus dont l'exécution en temps réel est critique. Mais en aucun cas ils ne garantissent alors que la pile logicielle de radiocommunication fonctionnera correctement. En outre, ceci implique une très grande complexité de conception de l'application client et donc une très forte expertise dans le domaine des radiocommunications (GSM/GPRS par exemple).
Pour ces raisons, cette seconde technique alternative est difficilement utilisable, notamment par les clients des marchés M2M et à plus forte raison de toute personne non experte à la fois dans le domaine d'application finale du produit global et dans le domaine des télécommunications, notamment des technologies GSM/GPRS.
De ce fait la majorité des architectures logicielles permettant d'embarquer du code externe sur une plateforme de radiocommunication (« Wireless platform » en anglais) sont conformes à la première technique connue et se définissent de la manière décrite dans la figure 1. Cette architecture logicielle comprend typiquement une pile logicielle de radiocommunication (dans l'exemple de la figure 1, une pile GSM, ou « GSM Stack » en anglais) comprenant : un gestionnaire d'interruptions de radiocommunication 1 (« GSM Stack IT Handler »), qui fournit des services de lien physique (« Physical Link Services ») et assure la synchronisation avec le réseau GSM. Il correspond à la couche physique GSM ; un ensemble de tâches 2 spécifiques à la pile GSM (« GSM Stack Tasks L1-L3 »), réparties en couches (Li a L3), et qui fournissent un service de contrôle et lien logique (« Logical Link and Control Service »). Dans la norme GSM, il correspond à Ll / L2 / L3, RR / LAPD / MM / CCRLC /
MAC / LLC / SNDCP / SM ; un ensemble de tâches 3 liées à des commandes AT (« GSM AT Commands Task »), qui fournissent un service de contrôle de la pile GSM. Dans la norme GSM, il correspond à la couche Application ; et - une tâche 4 dite « IdIe Task » ou « Tâche de fond » qui s'exécute lorsqu'aucune autre tâche ne demande la ressource CPU.
Cette architecture logicielle comprend en outre une application client 5 (dans cet exemple une application « Open AT »), comprenant un ensemble de tâches client. Au sein de la pile GSM, cette application client 5 est positionnées entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4. La flèche référencée 6 indique un axe de temps de réaction indicatif (depuis environ 1 ms jusqu'à environ 10 ms). La flèche référencée 7 indique un axe niveau de priorité (depuis la tâche de fond 4, qui est la moins prioritaire, jusqu'au gestionnaire d'interruptions de radiocommunication 1, qui est le plus prioritaire).
Cette architecture logicielle peut également être décomposée en deux domaines : - un domaine 8 de gestion des interruptions, dans lequel est compris le gestionnaire d'interruptions de radiocommunication 1 ; et un domaine 9 de gestion des tâches, dans lequel sont comprises toutes les tâches précitées (tâches 2 spécifiques à la pile GSM, tâches 3 liées à des commandes AT, tâche de fond 4 et tâches de l'application client 5). Ainsi, avec cette structure, toute application client peut être exécutée par le module tout en garantissant le bon fonctionnement de la stack GSM/GPRS. Néanmoins aucune capacité temps réel ne peut être garantie à cette application cliente.
Actuellement, comme illustré par la figure 2, un processeur (non représenté) interne au module 24 exécute une application principale de radiocommunication 24 qui gère la pile logicielle de radiocommunication (pile GSM par exemple). Afin de pallier l'absence de capacité temps réel pour l'application client 25 également exécutée par le module (grâce au processeur interne précité), on est obligé d'utiliser et implanter sur la carte-mère 21 du dispositif de radiocommunication, un processeur supplémentaire 22
(par exemple un microcontrôleur) et une mémoire supplémentaire 23, qui sont externes au module de radiocommunication 24 et permettent d'exécuter des processus client dont l'exécution temps réel est critique. En outre, dans cet exemple, le microcontrôleur 22 est relié à un connecteur 26 de dispositifs externes, via des interfaces d'Entrées/Sorties à usages divers (GPIOs) 27, des interfaces série de type SPI (Sériai Peripheral Interface)
(SPIl, SPI2) 28 et 29, une interface USB 210 et une liaison véhiculant des interruptions (IT) 211.
Ces éléments supplémentaires (microcontrôleur et mémoire) augmentent la complexité et le coût de fabrication du dispositif de radiocommunication.
Il existe donc un besoin d'offrir une capacité temps réel pour l'application client exécutée par le module, afin de se passer de la nécessité d'utiliser un processeur supplémentaire et une mémoire supplémentaire, externes au module de radiocommunication. 3. OBJECTIFS DE L'INVENTION
L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de gestion de l'architecture logicielle d'un circuit de radiocommunication, permettant d'exécuter une application client étrangère à la pile de radiocommunication, à un très haut niveau de priorité (ce qui permet d'exécuter des processus dont l'exécution en temps réel est critique), tout en garantissant le bon fonctionnement de cette pile de radiocommunication. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique, qui soit simple à mettre en œuvre et peu coûteuse.
Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique, qui permette de se passer de la nécessité d'utiliser un processeur supplémentaire et une mémoire supplémentaire, externes au circuit de radiocommunication.
Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique, qui puisse être mise en œuvre quelle que soit la quantité de traitement qu'implique l'exécution de l'application client.
4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, ladite architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client, ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication et au moins une tâche de radiocommunication, ladite application client comprenant au moins une tâche client. Le procédé comprend une étape d' intercalage, au sein de ladite pile logicielle de radiocommunication, d'au moins un gestionnaire d'interruptions client, compris dans ladite application client, et appartenant au groupe comprenant : un premier gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication et moins élevé que ledit gestionnaire d'interruptions de radiocommunication ; un second gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication et plus élevé que ledit gestionnaire d'interruptions de radiocommunication.
Le principe général de l'invention consiste donc à définir une nouvelle architecture logicielle, en ajoutant au sein de la pile de radiocommunication au moins un gestionnaire d'interruptions client, ayant un niveau de priorité d'exécution inférieur ou supérieur à celui du gestionnaire d'interruptions de radiocommunication, et supérieur à celui des tâches de radiocommunication. En d'autres termes, à travers le gestionnaire d'interruptions client, on offre aux développeurs d'applications client (destinées à être exécutées par le circuit) l'accès à des ressources matérielles bas niveau afin de respecter des premières contraintes temporelles critiques (par exemple un temps de réaction de moins de 1 ms). Ainsi, on garantit que l'application client peut traiter des interruptions en temps réel, sans mettre en danger le bon fonctionnement de la pile de radiocommunication. De façon avantageuse, ladite application client comprend au moins deux sous- ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client. En outre, le procédé comprend une étape de gestion desdits au moins deux sous-ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client par au moins une tâche de radiocommunication.
Ainsi, au sein du domaine de gestion des tâches (partie de la pile relative aux tâches), certaines tâches client ont un niveau de priorité d'exécution plus élevé que d'autres, ce qui permet à ces tâches client d'être exécutées en respectant des secondes contraintes temporelles critiques (par exemple un temps de réaction compris entre 1 ms et 10 ms), moins fortes que les premières précitées.
Avantageusement, au moins un desdits sous-ensembles de tâche(s) client comprend une tâche client particulière formant un troisième gestionnaire d'interruptions client recevant au moins une interruption par l'intermédiaire d'au moins un desdits premier et second gestionnaires d'interruptions client ou d'un autre troisième gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ledit troisième gestionnaire d'interruptions client. Ainsi, une application client peut comprendre plusieurs gestionnaires d'interruptions client, ayant différents niveaux de priorité d'exécution et s 'intercalant, au sein de la pile de radiocommunication, entre différentes tâches de radiocommunication.
Ces gestionnaires d'interruptions client sont organisés en cascade, en s'envoyant des interruptions (dans le sens décroissant des niveaux de priorité d'exécution).
De façon avantageuse, lesdites interruptions client appartiennent au groupe comprenant : des interruptions client externes audit circuit de radiocommunication ; et des interruptions client internes audit circuit de radiocommunication, comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication.
Selon une caractéristique avantageuse, la durée maximale d'exécution d'au moins un processus critique nécessaire pour la conception d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client est prédéterminée.
Dans un mode de réalisation avantageux de l'invention, le procédé comprend une étape de contrôle de la durée d'exécution d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée.
Dans un mode de réalisation particulier de l'invention, ledit circuit est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication.
Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution des étapes du procédé précité, lorsque ledit programme est exécuté sur un ordinateur.
Dans encore un autre mode de réalisation, l'invention concerne un circuit de radiocommunication, comprenant des moyens de gestion d'une architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client, ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication et au moins une tâche de radiocommunication, ladite application client comprenant au moins une tâche client. Le circuit comprend des moyens d'intercalage, au sein de ladite pile logicielle de radiocommunication, d'au moins un gestionnaire d'interruptions client, compris dans ladite application client, et appartenant au groupe comprenant : un premier gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication et moins élevé que ledit gestionnaire d'interruptions de radiocommunication ; - un second gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication et plus élevé que ledit gestionnaire d'interruptions de radiocommunication. Les différents moyens d'intercalage précités sont par exemple des éléments logiciels résultant de l'exécution, par un processeur compris dans le circuit, d'une l'application principale de radiocommunication (généralement appelée « fïrmware »).
Plus généralement, le circuit selon l'invention comprend des moyens de mise en œuvre du procédé de gestion de l'architecture logicielle, tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), et des dessins annexés, dans lesquels : - la figure 1 présente une architecture logicielle connue, d'une pile GSM supportant la capacité d'exécution d'une application client, sans capacité temps réel pour cette application client ; la figure 2 présente un dispositif de radiocommunication selon l'art antérieur, comprenant un module de radiocommunication possédant une architecture logicielle selon la figure 1 ; les figures 3A, 3B, et 3C présentent chacune une architecture logicielle selon respectivement un premier, un second et un troisième mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution d'une application client, avec capacité temps réel pour cette application client ; - la figure 4 présente un mode de réalisation particulier d'un dispositif de radiocommunication selon l'invention, comprenant un module de radiocommunication possédant une architecture logicielle selon l'une quelconque des figures 3A, 3B ou 3C ; et la figure 5A illustre un exemple d'utilisation de l'exemple d'architecture logicielle selon l'invention de la figure 3 A ; la figure 5B illustre un exemple d'utilisation de l'exemple d'architecture logicielle selon l'invention de la figure 3B. 6. DESCRIPTION DÉTAILLÉE
Sur toutes les figures du présent document, les éléments identiques sont désignés par une même référence numérique.
Les figures 1 et 2 sont relatives à l'art antérieur et ont déjà été décrites ci-dessus.
On présente maintenant, en relation avec la figure 3 A, une architecture logicielle selon un premier mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution d'une application client, avec capacité temps réel pour cette application client.
Dans ce premier mode de réalisation particulier, l'invention consiste à fournir aux utilisateurs de l'environnement « OPEN AT » la capacité d'exécuter du code étranger à la pile GSM/GPRS (c'est-à-dire une application client) sur une plateforme matérielle GSM/GPRS, à un très haut niveau de priorité (ce qui permet d'exécuter des processus dont l'exécution en temps réel est critique), tout en garantissant le bon fonctionnement de la pile GSM/GPRS dans les différents modes précités.
On rappelle que le concept « OPEN AT » est tel que, en plus de l'application principale de radiocommunication qui gère une pile logicielle de radiocommunication (pile GSM par exemple), un module de radiocommunication (par exemple de la famille « WISMO ») exécute au moins une application client. Dans ce premier mode de réalisation particulier de l'invention, l'architecture logicielle comprend une pile GSM et une application client.
La pile GSM est classique et identique à celle déjà décrite ci-dessus en relation avec la figure 1. Elle comprend donc un gestionnaire d'interruptions de radiocommunication 1 (« GSM Stack IT Handler »), un ensemble de tâches 2 spécifiques à la pile GSM (« GSM Stack Tasks L1-L3 »), un ensemble de tâches 3 liées à des commandes AT (« GSM AT Commands Task ») et une tâche de fond 4.
En revanche, l'application cliente de la figure 3 se distingue de celle de la figure 1 en ce qu'elle n'est pas monobloc mais comprend : - un premier gestionnaire d'interruptions client (Open AT IT Handler n°l)
31, géré de façon à être intercalé entre le gestionnaire d'interruptions de radiocommunication 1 et l'ensemble de tâches 2 spécifiques à la pile GSM ; une tâche client particulière formant un second gestionnaire d'interruptions client (Open AT IT Handler n°2) 32, gérée de façon à être intercalé entre l'ensemble de tâches 2 spécifiques à la pile GSM et l'ensemble de tâches 3 liées à des commandes AT ; et un ensemble de tâches client (« Open AT Application Tasks Tl ... T5), gérées de façon à être intercalées entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4.
Par rapport à l'architecture de l'art antérieur décrite sur la figure 1, cette architecture permet au client d'exécuter du code au niveau des premier et second gestionnaires d'interruptions client référencés 31 et 32.
Il est clair que différentes variantes de cet exemple peuvent être envisagées : avec un seul gestionnaire d'interruptions client ou bien avec plus de deux gestionnaires d'interruptions client, et/ou avec le(s) gestionnaire d'interruptions client intercalé(s) différemment au sein de la pile GSM, notamment comme illustré en relation avec les figures 3B et 3C.
L'exécution du code implémenté dans ces premier et second gestionnaires d'interruptions client est déclenchée par une interruption, qui peut être externe au module, ou interne pour le registre d'horloge (Hardware timer). Ceci permet l'exécution en temps réel de processus asynchrones. L'intérêt de cette solution est l'inter-corrélation entre d'une part la prise en compte des besoins temps réel de la pile GSM pour rester synchroniser au réseau et d'autre part des besoins d'exécution temps réel de n'importe quel type de traitement client (qui peut être très lourd), sans mettre en danger cette synchronisation au réseau.
De plus, la durée maximale d'exécution des processus critiques nécessaires pour la conception du code à exécuter au niveau des premier et second gestionnaires d'interruptions client 31, 32 et des tâches client 33 est prédéterminée. Il s'agit par exemple : - de la durée de non-interruptibilité (temps de latence d'interruption) ;
- du temps de planification (« Scheduling time » en anglais) ;
- du temps d'écriture en mémoire non volatile ;
- du temps d'allocation d'une zone de stockage en mémoire volatile ;
- du temps de positionnement de d'acquisition de valeurs sur les BUS et GPIOs de la plateforme ;
- le temps de basculement entre les modes actifs (normaux) et inactif (sleep) ;
- le temps de basculement entre les modes standard (26MHz) et Boost 104MHz ;
On présente désormais, en relation avec la figure 3B, une architecture logicielle selon un second mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution d'une application client, avec capacité temps réel pour cette application client.
À la différence de l'application client du premier mode de réalisation, l'application client du second mode de réalisation particulier comprend : - un premier gestionnaire d'interruptions client (Open AT IT Handler n°l) 310, géré de façon à avoir un niveau de priorité d'exécution plus élevé que le gestionnaire d'interruptions de radiocommunication 1 ; une tâche client particulière formant un second gestionnaire d'interruptions client (Open AT IT Handler n°2) 32, gérée de façon à être intercalé entre l'ensemble de tâches 2 spécifiques à la pile GSM et l'ensemble de tâches 3 liées à des commandes AT ; et un ensemble de tâches client (« Open AT Application Tasks Tl ... T5), gérées de façon à être intercalées entre l'ensemble de tâches 3 liées à des commandes
AT et la tâche de fond 4.
Ainsi, l'architecture logicielle selon ce second mode de réalisation particulier se distingue de celle selon le premier mode de réalisation particulier de la figure 3A en ce que le premier gestionnaire d'interruptions client (Open AT IT Handler n°l) 31 a un niveau de priorité d'exécution plus élevé que le gestionnaire d'interruptions de radiocommunication 1.
En conséquence, dans ce second mode de réalisation particulier, les utilisateurs de l'environnement « OPEN AT » ont la capacité d'exécuter du code étranger à la pile
GSM/GPRS (c'est-à-dire une application client) sur une plateforme matérielle
GSM/GPRS, à un niveau de priorité supérieur à celui de la pile GSM/GPRS (ce qui permet d'exécuter des processus dont l'exécution en temps réel est critique), tout en garantissant le bon fonctionnement de la pile GSM/GPRS dans les différents modes précités.
Les autres caractéristiques de fonctionnement restent identiques à celles décrites lors de la présentation de l'architecture logicielle du premier mode de réalisation en relation avec la figure 3A.
On présente désormais, en relation avec la figure 3C, une architecture logicielle selon un troisième mode de réalisation particulier de l'invention, d'une pile GSM supportant la capacité d'exécution d'une application client, avec capacité temps réel pour cette application client.
L'architecture logicielle selon ce troisième mode de réalisation particulier intègre un premier 320 et un second 330 gestionnaires d'interruptions client ayant chacun un niveau de priorité d'exécution supérieur à celui de l'ensemble des tâches 2 spécifique à la pile GSM.
Ainsi, à la différence de l'application client des premier et second modes de réalisation particulier de l'invention, l'application client de la figure 3C comprend : un premier gestionnaire d'interruptions client (Open AT IT Handler n°3) 330, géré de façon à avoir un niveau de priorité d'exécution plus élevé que le gestionnaire d'interruptions de radiocommunication 1 ; un second gestionnaire d'interruptions client (Open AT IT Handler n°l) 320, géré de façon à être intercalé entre le gestionnaire d'interruptions de radiocommunication 1 et l'ensemble de tâches 2 spécifiques à la pile GSM ; une tâche client particulière formant un troisième gestionnaire d'interruptions client (Open AT IT Handler n°2) 32, gérée de façon à être intercalé entre l'ensemble de tâches 2 spécifiques à la pile GSM et l'ensemble de tâches 3 liées à des commandes AT ; et un ensemble de tâches client (« Open AT Application Tasks Tl ... T5), gérées de façon à être intercalées entre l'ensemble de tâches 3 liées à des commandes AT et la tâche de fond 4.
Ainsi, grâce à cette architecture logicielle, un utilisateur peut utiliser le premier gestionnaire d'interruptions client (Open AT IT Handler n°3) 330 et le second gestionnaire d'interruptions client (Open AT IT Handler n°l) 320, suivant le temps de réponse à interruption recherché. Ainsi, par exemple, si l'utilisateur souhaite obtenir un temps de réponse inférieur à 20μs, il pourra intégrer le code de l'application client dans le premier gestionnaire d'interruptions client 330, et s'il se satisfait de temps de réponse par exemple d'ims (d'autres valeurs peuvent également être envisagées, par exemple 600 μs), il pourra disposer le code de l'application client dans le second gestionnaire d'interruptions client 320.
On présente maintenant, en relation avec la figure 4, un mode de réalisation particulier d'un dispositif de radiocommunication selon l'invention.
Il comprend une carte-mère 41 sur laquelle sont implantés un module de radiocommunication 44 possédant une architecture logicielle selon l'une quelconque des figures 3A, 3B ou 3C, obtenue par exécution par un processeur (non représenté) de : une application principale de radiocommunication 42 qui gère la pile logicielle de radiocommunication (pile GSM par exemple) et permet la mise en œuvre du procédé de l'invention, permettant d'obtenir l'architecture logicielle de l'invention (dans laquelle l'application client est répartie au sein de la pile) ; et une application client 45 dont les différentes parties sont réparties au sein de la pile GSM, comme détaillé ci-dessus en relation avec l'une quelconque des figures 3A, 3B ou 3C.
Du fait qu'une capacité temps réel est offerte à l'application client 45, aucun élément supplémentaire (ni microcontrôleur ni mémoire), externe au module, n'est nécessaire sur la carte-mère 41.
Par ailleurs, le module de radiocommunication 44 est relié à un connecteur 26 de dispositifs externes, via les mêmes interfaces et liaisons que celles déjà décrites sur la figure 2 (entre ce même connecteur 26 et le microcontrôleur externe 22). On présente maintenant, en relation avec la figure 5A, un exemple d'utilisation de l'exemple d'architecture logicielle selon l'invention de la figure 3A. Cet exemple porte sur : l'acquisition d'une valeur de courant par un capteur en un temps restreint et borné, temps après lequel la valeur remontée par le capteur n'a plus de valeur (par exemple 2 ms) ; le capteur positionnant une interruption au moment précis où la valeur est disponible. cet valeur (mesure) est acquise en vue du calcul de la consommation instantanée, de la moyenne sur plusieurs jours et du stockage du résultat en mémoire de manière asynchrone. - ces opérations de calcul et stockage devront se faire à chaque interruption positionnée par le capteur et ce de manière indépendante des modes GSM dans lesquels est le module. de manière hebdomadaire, le système complet envoie par GPRS le rapport de mesure complet (comportant par exemple plusieurs centaines de mesures ponctuelles).
On distingue les étapes suivantes :
1. Détection d'une interruption positionnée par le capteur signifiant que la mesure est prête à être acquise sur un bus quelconque de la plateforme.
2. Déclenchement du code client destiné à acquérir cette mesure dans un temps garanti de moins de 2ms (sinon la mesure n'a plus de valeur), ce code étant exécuté au niveau du premier gestionnaire d'interruption (Open AT IT Handler n°l).
3. Acquisition dans le premier gestionnaire d'interruptions client (Open AT IT Handler n°l) de la mesure et stockage en mémoire volatile (processus très rapide, quelques μs).
4. Notification par le premier gestionnaire d'interruption (Open AT IT Handler n°l) au second Gestionnaire d'interruption client (Open AT IT Handler n°2) que la mesure a été acquise et stockée en mémoire volatile à un emplacement donné. 5. Réveil du second Gestionnaire d'interruption client suite à la notification de mesure envoyée par le premier gestionnaire d'interruption. Acquisition de la valeur instantanée et exécution des calculs de consommation instantanée et moyenne dans le second gestionnaire d'interruptions client (Open AT IT Handler n°2). Stockage des résultats de ces calculs en mémoire flash (opérations très longues, plusieurs centaines de ms).
6. Retour à un état « normal » : attente d'interruption pour acquisition de valeur instantanée.
7. Chaque semaine, lorsque l'alarme que la tâche cliente Open AT (Open AT Application Tasks Tl) a positionnée sur « 1 semaine » se déclenche, cet tâche (Open AT Application Tasks Tl) va chercher à l'emplacement défini le rapport complet qui a été acquis, mis en forme et stocké par le second gestionnaire d'interruption suite aux mesures instantanées acquise en un temps limité par le premier gestionnaire d'interruption. 8. une fois le rapport acquis, la tâche cliente Open AT initie une connexion
GPRS et envoie le rapport et le supprime de la mémoire une fois l'envoi terminé. Il se peut que pendant cette phase les premier et second gestionnaires interrompent ces tâches (« OPEN AT Application Task Tl » et « GSM Stack Tasks ») pour acquérir de nouvelle valeurs). Les actions décrites aux étapes 7 et 8 sont synchrones (elles se répètent de manière prédictive : toutes les semaines, une fois par semaine) et ne nécessitent en aucun cas du temps réel puisque la réception du rapport de manière hebdomadaire par l'infrastructure cliente à plus ou moins 2 minutes prêt ne change absolument rien à la qualité du rapport et à son exploitation ultérieure. Ainsi ces actions sont exécutées par la tâche de basse priorité (Open AT Application Tasks Tl). A l'inverse, la qualité du rapport dépend de la qualité des mesures instantanées qui ne sont valables que si acquises en moins de 2 ms. Ici nous avons donc besoin de temps de réponse garanti. C'est pourquoi les mesures sont acquises par le premier gestionnaire d'interruption (Open AT IT Handler n°l).
Enfin l'envoi du rapport par GPRS pourrait modifier le temps d'acquisition de cette mesure instantanée car cela fait travailler la pile GSM. En cela, le client à besoin de l'architecture temps réel proposée par l'invention car elle seule peut lui garantir la qualité de ses mesures quelle que soit l'action que le système entreprend.
Si ces opérations 1 à 8 sont effectuées en mode déconnecté, elles se font de manière séquentielle puisque la pile GSM/GPRS ne tourne pas. Si le module est dans un des modes spécifiés plus hauts (quel qu'il soit), l'étape
2 est garantie car l'architecture logicielle selon l'invention garantit que le traitement d'une interruption (« GSM IT ») en provenance de la partie radio du module ne dure pas plus d' lms quel que soit le mode dans lequel le module est.
L'étape 3 (traitement de l'interruption client « EXT ITl ») ne commencera que lorsque l'interruption en provenance de la partie radio (« GSM IT ») sera traitée, ou cette étape 3 sera interrompue par le traitement de cette interruption. Ceci garantit que la synchronisation avec le réseau est conservée quel que soit le traitement asynchrone à réaliser en temps réel par l'application client. De plus, le fabricant du module garantit le temps maximum nécessaire à l'allocation d'une zone de stockage en mémoire volatile quel que soit l'état GSM du module. Ceci garantit que la mesure peut être stockée moins de 2ms après le déclenchement de l'interruption notifiant la nécessité de l'acquisition de cette mesure.
L'étape 4 (traitement de l'interruption client « EXT IT2 ») ne commencera que lorsque les tâches de la pile GSM/GPRS auront effectué les opérations nécessaires au maintien de l'appel voix, de l' envoi/réception des données sur le lien GPRS de l'envoi réception d'un SMS, USSD.... Cette découpe en termes de tâche permet donc d'exécuter des processus temps réel quel que soit l'état de la partie GSM/GPRS, tout en garantissant son bon fonctionnement de la pile.
Optionnellement, un processus de contrôle permet de s'assurer que le code client dans chacun des premier et second gestionnaires d'interruptions client (Open AT IT
Handler n°l et 2) ne s'exécute pas pendant trop longtemps.
On présente dorénavant, en relation avec la figure 5B, un exemple d'utilisation de l'exemple d'architecture logicielle selon l'invention de la figure 3B.
Dans cet exemple, on suppose qu'une succession de tâches est exécutée par le module de radiocommunication 44.
Ainsi, on peut distinguer les étapes suivantes : détection et traitement d'une première interruption « GSM IT » 51 en provenance du gestionnaire d'interruptions de radiocommunication 1 (« GSM Stack IT Handler »). L'architecture logicielle selon l'invention garantit que le traitement d'une interruption en provenance de la partie radio du module ne dure pas plus de lms ; détection et traitement d'une première interruption client « EXT IT 1 » 52 en provenance du premier gestionnaire d'interruptions client (« Open AT IT Handler n°l ») 310, un délai s 'étant écoulé entre la fin du traitement de la première interruption « GSM IT » 51 et la détection de la première interruption client « EXT IT 1 » 52 ; détection et traitement d'une seconde interruption de radiocommunication « GSM IT » 53 en provenance du gestionnaire d'interruptions de radiocommunication 1; - détection et traitement d'une seconde interruption client « EXT IT 1 » 54 en provenance du premier gestionnaire d'interruptions client 310. Le traitement de la seconde interruption de radiocommunication « GSM IT » 53 est suspendu au profit du traitement de la seconde interruption client « EXT IT 1 » 54 plus prioritaire. Lorsque le traitement de la seconde interruption client « EXT IT 1 » 54 est achevée, le traitement de la seconde interruption de radiocommunication
« GSM IT » 53 reprend jusqu'à son terme ; détection et traitement d'une troisième interruption client « EXT IT 1 » 55 en provenance du premier gestionnaire d'interruptions client 310. Lors du traitement de la troisième interruption client « EXT IT 1 » 55, une troisième interruption de radiocommunication « GSM IT » 56 est détectée. Cependant, le traitement de cette troisième interruption de radiocommunication « GSM IT » 56 ne commencera que lorsque le traitement de la troisième interruption client « EXT IT 1 » 55 sera achevée. Ainsi, il peut arriver que certaines interruptions de radiocommunication en provenance du gestionnaire d'interruptions de radiocommunication 1 soient décalées dans le temps au profit d'interruptions client en provenance du premier gestionnaire d'interruptions client 310 plus prioritaire.

Claims

REVENDICATIONS
1. Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication (44), ladite architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client (45), ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication
(1) et au moins une tâche de radiocommunication (2 à 4), ladite application client comprenant au moins une tâche client, caractérisé en ce que le procédé comprend une étape d'intercalage, au sein de ladite pile logicielle de radiocommunication, d'au moins un gestionnaire d'interruptions client, compris dans ladite application client, et appartenant au groupe comprenant : un premier gestionnaire d'interruptions client (31 ; 320) de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et moins élevé que ledit gestionnaire d'interruptions de radiocommunication
(i) ; - un second gestionnaire d'interruptions client (310 ; 330) de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et plus élevé que ledit gestionnaire d'interruptions de radiocommunication
(I)-
2. Procédé selon la revendication 1, caractérisé en ce que ladite application client (45) comprend au moins deux sous-ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client, et en ce que le procédé comprend une étape de gestion desdits au moins deux sous- ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client par au moins une tâche de radiocommunication.
3. Procédé selon la revendication 2, caractérisé en ce que au moins un desdits sous- ensembles de tâche(s) client comprend une tâche client particulière formant un troisième gestionnaire d'interruptions client (32) recevant au moins une interruption par l'intermédiaire d'au moins un desdits premier et second gestionnaires d'interruptions client ou d'un autre troisième gestionnaire d'interruptions client de niveau de priorité d'exécution plus élevé que ledit troisième gestionnaire d'interruptions client.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdites interruptions client appartiennent au groupe comprenant : des interruptions client externes audit circuit de radiocommunication ; et des interruptions client internes audit circuit de radiocommunication, comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la durée maximale d'exécution d'au moins un processus critique nécessaire pour la conception d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client est prédéterminée.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape de contrôle de la durée d'exécution d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit circuit est un module électronique de radiocommunication (44) destiné à être intégré à un dispositif de radiocommunication.
8. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon au moins une des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur.
9. Circuit de radiocommunication (44), comprenant des moyens de gestion d'une architecture logicielle comprenant une pile logicielle de radiocommunication et au moins une application client (45), ladite pile logicielle de radiocommunication comprenant un gestionnaire d'interruptions de radiocommunication (1) et au moins une tâche de radiocommunication (2 à 4), ladite application client comprenant au moins une tâche client, caractérisé le circuit comprend des moyens d' intercalage, au sein de ladite pile logicielle de radiocommunication, d'au moins un gestionnaire d'interruptions client, compris dans ladite application client, et appartenant au groupe comprenant : un premier gestionnaire d'interruptions (31 ; 320) client de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et moins élevé que ledit gestionnaire d'interruptions de radiocommunication
(i) ; un second gestionnaire d'interruptions client (310 ; 330) de niveau de priorité d'exécution plus élevé que ladite au moins une tâche de radiocommunication (2 à 4) et plus élevé que ledit gestionnaire d'interruptions de radiocommunication
(1).
10. Circuit de radiocommunication selon la revendication 9, caractérisé en ce que ladite application client (45) comprend au moins deux sous-ensemble de tâche(s) client, qui comprennent chacun au moins une tâche client, et en ce que le circuit comprend des moyens de gestion desdits au moins deux sous- ensemble de tâche(s) client permettant, au sein de ladite pile logicielle de radiocommunication, de séparer lesdits au moins deux sous-ensemble de tâche(s) client par au moins une tâche de radiocommunication.
11. Circuit de radiocommunication selon la revendication 10, caractérisé en ce que les moyens d'exécution d'au moins un desdits sous-ensembles de tâche(s) client comprennent des moyens d'exécution d'une tâche client particulière formant un troisième gestionnaire d'interruptions client (32) recevant au moins une interruption reçue par l'intermédiaire d'au moins un desdits premier et second gestionnaires d'interruptions client.
12. Circuit de radiocommunication selon l'une quelconque des revendications 9 à
11, caractérisé en ce que lesdites interruptions client appartiennent au groupe comprenant : des interruptions client externes audit circuit de radiocommunication ; et des interruptions client internes audit circuit de radiocommunication, comprenant des interruptions provenant d'un registre d'horloge compris dans ledit circuit de radiocommunication.
13. Circuit de radiocommunication selon l'une quelconque des revendications 9 à
12, caractérisé en ce que la durée maximale d'exécution de chaque processus critique nécessaire pour la conception d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client est prédéterminée.
14. Circuit de radiocommunication selon l'une quelconque des revendications 9 à
13, caractérisé en ce qu'il comprend des moyens de contrôle de la durée d'exécution d'au moins un desdits premier et second gestionnaires d'interruptions client et/ou d'au moins une desdites tâches client, permettant de s'assurer que ladite la durée d'exécution n'excède pas une durée maximale déterminée.
15. Circuit de radiocommunication selon l'une quelconque des revendications 9 à
14, caractérisé en ce qu'il s'agit d'un module électronique de radiocommunication (44) destiné à être intégré à un dispositif de radiocommunication.
EP07803445A 2006-09-12 2007-09-12 Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants Withdrawn EP2067099A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0607968A FR2905819B1 (fr) 2006-09-12 2006-09-12 Procede de gestion de l'architecture logicielle d'un circuit de radiocommunication,application,produit programme d'ordinateur et circuit correspondants.
PCT/EP2007/059601 WO2008031855A2 (fr) 2006-09-12 2007-09-12 Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants

Publications (1)

Publication Number Publication Date
EP2067099A2 true EP2067099A2 (fr) 2009-06-10

Family

ID=37943895

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07803445A Withdrawn EP2067099A2 (fr) 2006-09-12 2007-09-12 Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants

Country Status (4)

Country Link
US (1) US8127064B2 (fr)
EP (1) EP2067099A2 (fr)
FR (1) FR2905819B1 (fr)
WO (1) WO2008031855A2 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2503471B (en) * 2012-06-27 2015-05-06 Nordic Semiconductor Asa Integrated-circuit radio
GB2521607B (en) 2013-12-23 2016-03-23 Nordic Semiconductor Asa Integrated-Circuit Radio
US10140309B2 (en) * 2014-06-10 2018-11-27 Alfresco Software, Inc. File tracking on client machines synchronized with a content management system repository
GB2541133B (en) 2015-06-16 2018-01-03 Nordic Semiconductor Asa Interrupt generating unit
CN105630492B (zh) * 2015-12-21 2019-05-31 北京奇虎科技有限公司 一种应用的周期任务封装的方法以及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2760922B1 (fr) * 1997-03-12 1999-05-07 Sagem Procede d'echange de donnees, avec adaptation, entre un reseau radio de communication et des moyens de traitement de donnees
EP1213648A1 (fr) * 2000-12-05 2002-06-12 Infineon Technologies AG Méthode pour coordiner des tâches dans un réseau GSM
US6694331B2 (en) * 2001-03-21 2004-02-17 Knowledge Management Objects, Llc Apparatus for and method of searching and organizing intellectual property information utilizing a classification system
FR2830403B1 (fr) * 2001-10-02 2003-11-21 Wavecom Sa Module de radiocommunication executant un logiciel principal dont les couches sont ouvertes a un logiciel client egalement execute par le module

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US20090318078A1 (en) 2009-12-24
WO2008031855A2 (fr) 2008-03-20
FR2905819A1 (fr) 2008-03-14
US8127064B2 (en) 2012-02-28
WO2008031855A3 (fr) 2008-11-27
FR2905819B1 (fr) 2013-01-18

Similar Documents

Publication Publication Date Title
EP2735969B1 (fr) Ensemble électronique comprenant un module de desactivation
EP2067099A2 (fr) Procédé de gestion de l'architecture logicielle d'un circuit de radiocommunication, application, produit programme d'ordinateur et circuit correspondants
FR2915006A1 (fr) Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.
EP3395090A1 (fr) Procede de controle d'un module d'identite de souscripteur embarque
WO2005066888A1 (fr) Information pleinement simultanee de variations de statuts pour un objet a interface duale
EP2168283A1 (fr) Procede de detection du brouillage d'un reseau de radiocommunication, produit programme d'ordinateur, moyen de stockage et circuit correspondants
CN110673955A (zh) 优化内存的方法、装置、系统、终端和存储介质
EP1371251B1 (fr) Module de radiocommunication hebergeant et executant un logiciel client, et procede correspondant de mise en oeuvre d'un logiciel client de pilotage
FR2836611A1 (fr) Procede de communication reseau avec une carte a puce par messages asynchrones
WO2015092307A1 (fr) Procédé de test et de mise à jour du système d'un terminal par un module d'identité de souscripteur et dispositifs associés
FR3051585B1 (fr) Procede et systeme de transmission d'une alerte geolocalisee a un utilisateur muni d'un terminal mobile de communication
WO2009010536A1 (fr) Procede de gestion de l'execution d'une architecture logicielle d'un circuit de radiocommunication en jouant sur la frequence du processeur, produit programme d'ordinateur et circuit correspondants
EP3317800B1 (fr) Procédé de gestion de profils dans un élément sécurisé
WO2009010535A1 (fr) Procede de gestion de l'execution d'une architecture logicielle d'un circuit de radiocommunication a frequence processeur constante, produit programme d'ordinateur et circuit correspondants
EP1433343B1 (fr) Module de radiocommunication executant un logiciel principal dont les couches basses sont ouvertes a un logiciel client egalement execute par le module
EP3502949A1 (fr) Procédé et système de contrôle d'ordonnancement de tâches logicielles
FR3113634A1 (fr) Procédé et système de supervision de clés digitales de véhicules
EP3391695B1 (fr) Procédé de gestion du fonctionnement d'un objet connecté
WO2022167738A1 (fr) Procédé et dispositif de communication entre un véhicule et un dispositif de communication mobile
FR2985878A1 (fr) Procede de selection d'un protocole de transport de messages
FR2896934A1 (fr) Composant integre comprenant des circuits de gestion de l'alimentation et de gestion des etats d'urgence
FR2998747A1 (fr) Procede d'aiguillage d'un message
FR2942053A1 (fr) Procede et systeme de validation d'une commande de suspension d'activite d'au moins une ressource d'un terminal
WO2011054706A2 (fr) Procede de sauvegarde de l'activite informatique d'un dispositif electronique
EP1371252A1 (fr) Module de radiocommunication executant un logiciel principal et un logiciel client comprenant plusieurs applications clientes

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: 20090409

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090623

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160401