FR3114671A1 - Embedded secure element - Google Patents

Abstract

Embedded secure element This description relates to an embedded electronic system or a method implemented by such a system, comprising: at least one volatile memory (RAM); and at least one low-level operating system managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications, wherein said volatile memory comprises: at least a first part ( PRAM30) reserved for execution data of a first application (App30); and at least a second part intended to store execution data of at least one second application (App31), the execution data of the first application remaining in the volatile memory in the event of deactivation or standby of this first app. Figure for the abstract: Fig. 4

Description

Embedded secure element

The present description generally relates to electronic systems and, more particularly, to on-board electronic systems. The present description relates, even more particularly, to the use of memories in an on-board electronic system.

An embedded electronic system is an autonomous electronic and software system adapted to be embedded in an electronic device and/or electronic equipment.

The difficulties of designing an embedded system are frequently linked to internal or external memory management constraints to the embedded system. The system can comprise rewritable or non-rewritable non-volatile memories and volatile memories, each suitable for storing data of different types with the constraints and advantages specific to each type of memory. The management of these memories generates constraints in terms of data security, in particular when the system is used for different applications.

It would be desirable to be able to improve, at least in part, certain aspects of known on-board electronic systems, more particularly to be able to improve, at least in part, certain aspects of the use of memories in on-board electronic systems.

There is a need for embedded systems adapted to manage several applications independently of each other.

There is, more particularly, a need for on-board systems in which the use of memories is optimized.

An embodiment of a first aspect provides an on-board electronic system comprising:
- at least one volatile memory; And
- at least one low-level operating system managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications,
wherein said volatile memory includes:
at least a first part reserved for execution data of a first application; And
at least a second part intended to store execution data of at least a second application,
the execution data of the first application remaining in the volatile memory in the event of deactivation or standby of this first application.

An embodiment of the first aspect provides a method implemented by an on-board electronic system comprising:
- at least one volatile memory; And
- at least one low-level operating system managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications,
wherein said volatile memory includes:
at least a first part reserved for execution data of a first application; And
at least a second part intended to store execution data of at least a second application,
the execution data of the first application remaining in the volatile memory in the event of deactivation or standby of this first application.

According to an embodiment of the first aspect, execution data of one or more tasks of an application are transferred, in whole or in part, by the low-level operating system, from said volatile memory to a memory non-volatile when the execution of said task is interrupted by the execution of at least one task of another application.

According to an embodiment of the first aspect, a volatile memory area is allocated to the second application when it is not executed, the execution data of this second application being transferred to non-volatile memory if the memory size volatile available is not enough to run a third application.

An embodiment of a second aspect provides an on-board electronic system comprising:
- at least one volatile memory;
- at least one low-level operating system managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications,
wherein execution data of one or more tasks of said first application is transferred, in whole or in part, by the low-level operating system, from said volatile memory to a non-volatile memory when the execution of said task of the first application is interrupted by the execution of at least one task of a second application.

An embodiment of the second aspect provides a method implemented in an on-board electronic system comprising:
- at least one volatile memory;
- at least one low-level operating system managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications,
wherein execution data of one or more tasks of said first application are transferred, in whole or in part, by the low-level operating system, from said volatile memory to an area of a non-volatile memory when that the execution of said task of the first application is interrupted by the execution of at least one task of a second application.

According to an embodiment of the second aspect, in which a volatile memory area is allocated to the first application while it is not being executed, the data of this first application being transferred to non-volatile memory if the available volatile memory size is not sufficient for the execution of a second application

According to an embodiment of one or the other of the aspects, the applications of a high-level operating system do not have access to the areas of the volatile memory allocated to the applications of another operating system high level.

According to an embodiment of one or the other of the aspects, a memory management function or unit executed by the low-level operating system prevents the access of the execution data of an application to other apps.

According to an embodiment of the first aspect, the memory management function or unit adapts the size of the first and second parts of the volatile memory according to the needs of the different applications.

According to an embodiment of one or the other of the aspects, the execution data of several applications are simultaneously present in volatile memory.

According to an embodiment of one or the other of the aspects, the non-volatile memory is external to the on-board electronic system.

According to an embodiment of one or other of the aspects, an application execution code is transferred to volatile memory for its execution.

According to an embodiment of one or other of the aspects, the non-volatile memory is internal to the on-board electronic system.

According to an embodiment of one or the other of the aspects, an application execution code remains in non-volatile memory during the execution of a task.

According to an embodiment of one or the other of the aspects, a non-volatile memory zone allocated to a high-level operating system is seen by the latter as a volatile working memory.

According to an embodiment of one or the other of the aspects, the high-level operating systems manage a virtual image of the memories in which the volatile and non-volatile memories are one.

According to an embodiment of one or other of the aspects, during its execution, a main task of an application is allocated a volatile memory area.

One embodiment provides an embedded secure element, configured for implementing the system or the method described.

These characteristics and advantages, as well as others, will be set out in detail in the following description of particular embodiments given on a non-limiting basis in relation to the attached figures, among which:

there represents, schematically and in the form of blocks, an embodiment of hardware constituents of an on-board secure element or on-board electronic system;

there represents, schematically and in the form of blocks, a software architecture of an on-board electronic system;

there represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, the implementation of a method for executing applications of the on-board electronic system of FIGS. 1 and 2;

there represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, an embodiment of a method for executing applications of the on-board electronic system of FIGS. 1 and 2 ;

there represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, the implementation of a method for executing applications of the on-board electronic system of FIGS. 1 and 2; And

there represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, another mode of implementation of a method for executing applications of the on-board electronic system of FIGS. 1 and 2.

The same elements have been designated by the same references in the various figures. In particular, the structural and/or functional elements common to the various embodiments may have the same references and may have identical structural, dimensional and material properties.

For the sake of clarity, only the phases and elements useful for understanding the embodiments described have been represented and are detailed.

Unless otherwise specified, when reference is made to two elements connected together, it means directly connected without intermediate elements other than conductors, and when reference is made to two elements connected or coupled together, it means that these two elements can be connected or be linked or coupled through one or more other elements.

In the following description, when referring to absolute position qualifiers, such as "front", "rear", "up", "down", "left", "right", etc., or relative, such as the terms "above", "below", "upper", "lower", etc., or to qualifiers of orientation, such as the terms "horizontal", "vertical", etc., it reference is made unless otherwise specified to the orientation of the figures.

Unless specified otherwise, the expressions “about”, “approximately”, “substantially”, and “of the order of” mean to within 10%, preferably within 5%.

There represents, very schematically and in the form of blocks, an embodiment of material constituents HW (Hardware) of an on-board secure element E or on-board electronic system.

Element E is made in the form of an electronic circuit comprising, in material form,:
- one or more digital processing unit 11 (PU), for example of the state machine, microprocessor or central processing unit (CPU) type, programmable logic circuit, etc.; ;
- One or more memories 12, 13 for volatile storage (RAM) and/or non-volatile storage (NVM) of data and programs;
- One or more buses 14 for data, addresses and/or commands between the various elements internal to circuit 1;
- one or more input-output (I/O) interfaces 15 for wired or wireless communication with the outside of the circuit
1;
- One or more communication circuits, for example a near field communication circuit 16 (NFC – Near Field Communication); And
- various other circuits depending on the application, symbolized in by a block 17 (FCT), for example a short-distance communication device using, for example, the Bluetooth standard, biometric sensors, etc. .

There represents, schematically and in the form of blocks, a software architecture 100 of an embedded secure element E, or secure embedded electronic system.

The software architecture 100 is implemented by the hardware components HW of the secure element E described in .

The architecture 100 comprises a primary platform 110, generally designated virtual primary platform (Virtual Primary Platform VPP) comprising access to the electronic components 111 (HW) of the secure element E, and comprising one or more base operating systems level 113 (LLOS, Low Level Operating System).

The low-level operating systems 113 are operating systems making it possible to facilitate communication between one or more high-level operating systems (HLOS1, HLOS2, HLOS, High Level Operating System) 124A, 124B (two systems of high-level operation in the case illustrated in ) of the secure element E and the components 111 of the element E. By way of example, the low-level operating systems include driver software for the components 111.

A low-level operating system 113 is composed of runtime code (or executable code) and runtime data. The runtime code contains instructions for executing program functions. By definition, the instructions are invariable for a given program, with the exception of an update of the program which then modifies the instructions. Runtime data is used by runtime code to contextualize execution and perform the desired function. Runtime data can be broken down into two categories. The so-called "temporary" execution data and the so-called "permanent" or "fixed" execution data. For example, if the function consists of the verification of a PIN code, this function is broken down into three parts, the execution code contains instructions for verifying the PIN code while the permanent execution data contains the PIN code of reference and the number of remaining trials and that the temporary execution data contains the PIN code subject to verification.

In an embedded secure element, the low-level system manages the element's memory components, that is to say the physical, volatile memories 12 ( ) and non-volatile 13 (rewritable or not).

The high-level operating systems 124A and 124B use virtual images of the available memories for the management of execution codes and execution data. Thanks to this technique, high-level operating systems do not have direct access to the management of physical memories, whether volatile or non-volatile. In other words, in the embodiments described, the high-level operating systems manage a virtual memory image in which the volatile memory(s) and non-volatile memory(s) are one. The management of the physical distribution in the volatile(s) and non-volatile(s) memories is ensured by the low-level operating system(s).

The platform 110 has, according to the embodiments described, in particular for roles;
- to define a low-level operating system between the hardware components (HW), in particular the processor and the memories, and the high-level operating systems and the applications they run;
- manage exchanges between high-level operating systems and hardware components;
- to implement a function (firewall or firewall) preventing interaction between high-level operating systems; And
- to allow sharing of the same hardware components of the secure element between several high-level operating systems while ensuring that only one is active at a given time.

The low-level operating system 113 uses a memory management function 115 (Memory Management Function – MMF) to control or manage the access of the high-level operating systems to the physical memories by creating the link between the virtual memories and the physical memories according to the needs and demands of the high level operating systems 124A and 124B. More particularly, the low level operating systems 113, using the memory management function 115 (MMF), implement the isolation of the high level operating systems 124A and 124B from each other and manage the access of high-level operating systems 124A, 124B to the various memories. For example, the low-level operating systems 113 can manage the data stored in said memories, and more particularly, manage the access to this data, especially in the case where several high-level operating systems are present in the memory. secure element E. Low-level operating systems 113 can, for example, prohibit access to certain data by a high-level operating system.

The architecture 100 further comprises applications adapted to be implemented by the primary platform 110. These applications are, for example, adapted to process commands originating from communication interfaces, such as for example a banking transaction using a near field communication device. Each of these applications is implemented using fixed data forming the application, for example instructions, lines of code, or permanent data such as user data such as an identifier, and temporary data, data execution, or variables like data stacks, temporary encryption keys. Runtime data of an application is data used by the application only during its execution and not retained after the execution of the application is finished.

More particularly, an application implements one or more tasks, each task being, for example, a succession of instructions. It is the implementation of a task that produces execution data. Some runtime data may be used by different tasks in the application, while some may only be used by a single task. It is considered that an application can only be implemented with one task at a time.

Thus, in the rest of the description, the term "main task" refers to the task which is being executed by the application and "secondary tasks" to the other tasks of the application which are not being executed. The execution tasks are for example tasks which have not yet been implemented, and which have not made it possible to generate execution data, or tasks which have already been implemented but which have been , for example, interrupted (and paused), and therefore have already generated runtime data. Thus, in the remainder of the description, a distinction is made between execution data relating to the main task and execution data relating to the secondary tasks.

These applications can be of different types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application allowing the validation of a public transport ticket, etc.

According to an example of the type of application, an application 121 (App1) is adapted to be implemented directly by the primary platform 110. The application 121 is, for example, an application making it possible to make payments by communicating with a Near Field Communication (NFC) device.

According to another example of the type of application, an application 122 (App2) is adapted to send commands to the primary platform 110 via one of the high-level operating systems, for example the operating system 124B. This high-level operating system can be, for example, one of the operating systems of the secure element E exchanging commands with the primary platform 110. As a variant, it can also be considered that the operating system level, as well as all the applications which are attached to it, are an application adapted to be implemented by the primary platform 110.

According to another example of the type of application, an application 123 (App3) is adapted to send commands to the primary platform 110 via an execution environment 125 (ENV) and one of the control systems. high level exploitation, for example the 124A operating system. The operating environment is for example of the Java or JavaCard type. As a variant, it is also possible to consider that the operating system, as well as all the applications which are attached to it, are an application adapted to be implemented by the primary platform 110.

To implement these different applications 121, 122, 123, the operating systems 124A, 124B, and the execution environment 125, the components 111 of the secure element E comprise, more particularly, at least one memory not volatile and at least one volatile memory. Nonvolatile memory is generally used to store fixed data and the execution code of one or more applications. Volatile memory is typically used to store runtime data for one or more applications. In the case where the fixed data and the execution data of several applications are stored at the same time in the volatile memory and in the non-volatile memory, there is a protection, for example a software protection and/or a firewall mechanism. fire, allowing to prevent an application from accessing the fixed data and the execution data of another application. This function is, as indicated above, implemented by a memory management function 115 MMF (Memory Management Function) or memory management unit (Memory Management Unit – MMU). This function 115 is used to make the link between the "virtual" memory known by the application and the physical memories (volatile and non-volatile). High-level operating systems (124A and 124B) do not have "direct" access to physical memory management. They use a virtual image of this memory. However, the management of this virtual image or virtual memory is cut out in order to allow the high level operating systems (124A and 124B) to manage the execution codes, as well as the fixed data or the execution data according to of their nature. It is the high-level operating systems that manage their data and not the low-level operating systems. Low-level operating systems and memory management function map virtual runtime data (virtual memory) to its physical memory storage.

According to one embodiment, at least one zone or part of the non-volatile memory is used as a working memory. In other words, this area of the non-volatile memory functions, seen from high-level applications, like a volatile memory, to store temporary data used by the applications during their operation. The non-volatile memory can be internal or external to the secure element E (internal or external to the circuit HW). Depending on whether the non-volatile memory (its area used in working memory by high-level operating systems) is internal or external to the secure element, the management of this memory differs when running a system. high-level operation.

In the case where the non-volatile memory is internal to the secure element E, the high-level operating system can be directly executed from the memory where the operating system is located (is loaded). We speak of execution "in place" (XIP) or "in place". In general, low-level operating systems then allow the management of the execution of several high-level operating systems. In the case where an application is executed "in place", the instructions part (the execution code) of the application remains in non-volatile memory. Execution data (permanent and temporary) is moved to working memory (non-volatile memory), if necessary.

Conversely, if the non-volatile memory is external to the secure element E, "in place" execution is not possible. Non-volatile memory management involves moving all or part of the high-level operating system into an internal volatile memory of the secure element. In this case, the low-level operating system may or may not authorize the management of the execution of several high-level operating systems in its internal memory.

Furthermore, it is considered that an application can be in at least three different states:
- an active or running state (running) by the primary platform 110;
- a standby state, that is to say that its execution is interrupted but that it can resume at any time; And
- an inactive or deactivated state, ie its execution cannot be restarted without one or more prior operations.

When an app wakes up to run again, it resumes running where it left off. She does not need to use any particular routine to continue her processing. From the application's point of view, everything appears as if the application has not been interrupted.

More particularly, when an application is being executed, all or part of the data relating to its main task are stored in the volatile memory of the circuit and are used for the implementation of the application. Data relating to secondary tasks of the application can be stored in volatile memory or in working (non-volatile) memory. As a variant, certain execution data (permanent or temporary) relating to the main task can be found in the working memory (non-volatile) and be loaded into the volatile memory when the main task needs it.

When an application is in standby, the data relating to its main task are stored in the volatile memory and are not in use for the implementation of the application. Data relating to secondary tasks of the application can be stored in volatile memory or in working memory. An application may additionally sleep if its execution is interrupted by the execution of another application which may be in a different high-level operating system. In this case, all the tasks of the sleeping application are considered secondary tasks since none are executed. Thus, when an application is on standby because another application is running, all of its data is found physically, either in a dedicated area of volatile memory not accessible to other operating systems , or in non-volatile memory. This management is carried out by the memory management function 115. However, seen from the application (of the high-level operating system), the temporary data are in an assimilated working memory, by the virtual image that uses this operating system, to volatile memory. According to another exemplary embodiment, execution data of several different applications of several different high-level operating systems are found at the same time in the volatile memory. In this case, each application only has access to its own data and does not have access to the data of the other or in other applications. By using the low-level system and the memory management function, the applications are not aware of the presence of data from other applications in the volatile memory.

When an application is deactivated, all its data (whether related to a main task or to a main task) is stored in memory in the same way as for a sleeping application.

FIGS. 3 to 6 illustrate different implementations of applications of the secure element E, and more particularly the use of volatile and non-volatile (working) physical memories.

One would have thought to let the high-level operating systems directly manage the volatile 12 and non-volatile 13 memories. with non-volatile memory management by a high-level operating system. Passing this management to the low-level operating system and "trick" the high-level operating system that it is transferring its data to volatile memory speeds up the process.

There comprises three views (a), (b), and (c) each illustrating a phase of an implementation of a method for executing applications App20 and App21 of the secure element E described in relation to the figures 1 and 2. These three views more particularly illustrate the use of working memory WM using non-volatile memory (Physical NVM), considered by applications to be volatile memory, and real volatile RAM (Physical RAM), of the secure element E during the execution of the applications App20 and App21.

App20 and App21 applications, depending on their implementation, can be in the same high-level operating system or in two different high-level operating systems.

According to the example described in , it is assumed that the App21 application is deactivated, but has already been started, before the App20 application is started. The execution data relating to the main and secondary task of the application App21 are stored in an area W21 of the non-volatile working memory WM.

The App20 application is also disabled but has never been started. It has therefore not yet generated any runtime data.

In a first phase (view (a)), the application App20 is started by the secure element E. More particularly, the application App20 is started by the low-level operating system 113. The application App20 is then running. Execution data relating to the main task of the App20 application is downloaded or loaded into the volatile RAM memory.

During its entire execution, and if it is not interrupted by the execution of another application, the App20 application stores its execution data in volatile RAM memory.

In a second phase (view (b)), it is assumed that the application App21, deactivated until now, requests to be executed by the secure element E.

The execution data relating to the main task, and, possibly, to secondary tasks, of the application App20, present in the volatile memory RAM are transferred and stored in a zone WM20 of the non-volatile working memory WM and are removed from volatile RAM memory. Thus, the current state of the App20 application is saved in the memory WM, seen by the App20 application as a volatile memory, and the App20 application then becomes deactivated.

Execution data relating to the App21 application previously stored in the WM21 zone are loaded into the volatile RAM memory. Thus, the use of the App21 application can resume where it left off previously. In other words, the App21 application goes from a deactivated state to a "running" state.

In a third phase (view (c)), the App21 application continues to run, and modifies in the volatile RAM memory its execution data relating to its main task and, possibly, to secondary tasks. Data are therefore transferred from the non-volatile working memory WM to the volatile memory PRAM.

There comprises three views (a), (b), and (c) each illustrating a phase of an embodiment of a method for executing applications App30 and App31 of the secure element E described in relation to FIGS. 1 and 2. These three views illustrate more particularly the use of the non-volatile working memory WM and of a volatile memory RAM of the secure element E during the activation of the applications App30 and App31.

App30 and App31 applications, depending on their implementation, can be in the same high-level operating system or in two different high-level operating systems.

According to one embodiment, the application App30 is a frequently used application, or resident application, or implements a frequently used task, a resident task. Whether an application is considered "frequent" is decided, requested, and/or indicated by the high-level operating system that hosts the application. The execution data relating to the resident application App30 is stored in a reserved area PRAM30 of the volatile RAM memory. The PRAM30 area (or range of physical addresses) of RAM memory is always available to store App30 application runtime data, and runtime data from one or more applications cannot be stored there. .

It is assumed that the App30 application is active and running.

In a first phase (view (a)), the App30 application is placed on standby. Execution data relating to the main task of the App30 application is stored in the PRAM30 area. The main task of the App30 application is, for example, a resident task.

The application App31 is then started by the secure element E. Execution data, relating to the main task, and, possibly to secondary tasks, of the application App31, are downloaded or loaded into a zone PRAM31 volatile RAM memory. The PRAM31 area is distinct from the PRAM30 area. The App31 application is then running.

Throughout its execution, and if it is not interrupted by the execution of another application, the App31 application stores its execution data in the PRAM31 area of the volatile RAM memory.

In a second phase (view (b)), the resident application App30, hitherto on standby, requests to be executed by the secure element E, more particularly, by the low-level operating system 113.

If the capacity of the volatile memory is not sufficient to contain the execution data of the App30 and App31 zones, the execution data relating to the App31 application, present in the PRAM31 zone of the volatile RAM memory, are then transferred to an area WM31 of the non-volatile working memory WM. Thus, the current state of the application App31 is saved in the working memory WM and the application App31 is then deactivated. This situation can also occur if two applications are already present in volatile memory and a third application requests to be executed.

In a third phase (view (c)), execution data relating to the main task of the application App30, already present in the area PRAM30 of the volatile RAM memory dedicated to the application 30, can be directly processed. Thus, the use of the App30 application can resume where it left off previously. The App30 application is then running.

An advantage of this embodiment is that a frequently used application, or resident application, is guaranteed to have room in the physical volatile memory PRAM to store its execution data. In the event that, the size of the resident volatile memory requested by a new resident application which should be activated would be greater than the size of the physical volatile memory PRAM, its activation would be refused until the PRAM memory is freed, or that the available size of the PRAM memory is sufficient, or that the size of the so-called resident memory requested by the application to be activated is compatible with the available size of the PRAM memory. This case can occur if several resident applications are activated.

There comprises three views (a), (b) and (c) each illustrating a phase of an implementation of a method for executing applications App40 and App41 of the secure element E described in relation to FIGS. 1 and 2. These three views more particularly illustrate the use of the non-volatile working memory WM and of the volatile memory RAM of the secure element E during the activation of the applications App40 and App41.

The App40 and App41 applications, depending on their implementation, could be in the same high-level operating system or in two different high-level operating systems.

It is assumed that the applications App40 and App41 have already been previously started or executed by the secure element E, but are now on standby or inactive. All the execution data relating to the starting and operation of the applications App40 and App41 are then stored in, respectively, areas WM40 and WM41 of the non-volatile working memory WM.

In a first phase (view (a)), the application App40 requests to be executed by the secure element E, and then becomes “running”. Start-up and operating execution data relating to the application App40 are transferred, downloaded or loaded into a zone PRAM40 of the volatile memory RAM, from the zone WM40 of the non-volatile working memory WM, when the task main application App40 needs it.

In a second phase (view (b)), the application App41 in turn requests to be executed by the secure element E. The execution data relating to the main task of the application App41 are transferred, downloaded or loaded in a zone PRAM41 of the volatile memory RAM, from the zone WM41 of the non-volatile working memory WM. These data are stored following the execution data relating to the App40 application in the volatile RAM memory. The App41 application is then running, and the App40 application is then on standby.

At a third phase (view (c)), the application App41 is still executed by the secure element E, but the volatile RAM memory no longer has space available to store additional execution data relating to this application App41. Execution data relating to secondary tasks of the application App40, present in the area PRAM40, are then transferred or moved to the area WM40 of the non-volatile memory WM to free up storage space in the volatile memory RAM .

It can also happen that data from the App41 application is transferred to working memory, for example if all the execution data of the App40 application has already been transferred to working memory but the memory capacity volatile is not sufficient for all App41 application runtime data. In this case, the least used or oldest data is transferred to working memory.

There comprises three views (a), (b), and (c) each illustrating a phase of an embodiment of a method for executing applications App50 and App51 of the secure element E described in relation to there . These three views illustrate more particularly the use of the non-volatile working memory WM and of the volatile memory RAM of the secure element E during the activation of the applications App50 and App51.

. The App50 and App51 applications, depending on their implementation, could be in the same high-level operating system or in two different high-level operating systems.

It is assumed that applications App50 and App51 have already been started by secure element E and are deactivated. All the execution data relating to the starting and operation of the applications App50 and App51 are respectively stored in areas WM50 and WM51 of the non-volatile working memory WM.

According to the example described in , the App50 application is a frequently used application, hereinafter called resident application, also described in relation to the .

In a first phase (view (a)), the resident application App50 requests to be executed by the secure element E. Execution, start-up and operating data relating to the application App50 are transferred, downloaded or loaded into a reserved PRAM50 area of the volatile RAM memory, from the WM50 area of the non-volatile working memory WM. The PRAM50 area is an area of volatile RAM memory that is always available to store App50 application runtime data, and cannot be used to store runtime data from other applications. The App50 application is then running.

In a second phase (view (b)), the App51 application requests to be executed by the secure element E. Startup and operating execution data relating to the App51 application are transferred, downloaded or loaded into a area PRAM51 of the volatile memory RAM, from area WM51 of the non-volatile working memory WM. These data are stored following the execution data relating to the App50 application in the volatile RAM memory. The App51 application is then running, and the App50 application is then on standby.

At a third phase (view (c)), the application App51 is still being executed by the secure element E, but the volatile RAM memory no longer has space available to store additional execution data relating to the App51 application. Since the execution data relating to the App51 application cannot be stored in the PRAM50 area, certain execution data relating to secondary tasks of the App51 application are then moved to the WM51 area of the non-volatile working memory WM to free up storage space in volatile RAM.

In the event that the secure element E needs to implement a third application, while the volatile RAM memory no longer has space available to store execution data, the low-level system (its MMF memory management) will move data from the oldest non-resident application.

Alternatively, a resident application has part of the execution data in dedicated volatile memory (resident) and another part in volatile memory shared with other applications. This shared part can then be transferred to working memory (non-volatile) when the execution of the task of the application concerned is interrupted or needs more space in volatile memory.

An advantage of the embodiments described is that all the applications are loaded into a memory seen, by the high-level operating systems of these applications, as a volatile memory. This allows a quick start of each application.

Another advantage of the described embodiments is that a frequently used application is guaranteed to have room in the circuit's volatile RAM memory to store its operating execution data.

Preferably, the low-level operating systems 113, described in connection with the , manage the allocation of memory zones and their filling with the runtime data of the applications (resident or not). More particularly, the low-level operating system or systems are adapted to detect whether an application is a resident application or not. A secure element E can comprise several resident applications. Low-level operating systems 113 are further adapted to refuse the installation of an application as resident application, for example, if the secure element E includes too many resident applications, in particular when Too much, for example more than half, of the volatile RAM memory is reserved for resident application execution data. According to a variant, the low-level operating systems 113 are adapted to configure the sizes of the portions of the volatile RAM memory reserved for the execution data of resident applications. In particular, the low-level operating systems 113 are suitable for configuring the size of a part of the volatile RAM memory reserved for execution data of a resident application, to make it equal to zero.

Moreover, if the secure element comprises several resident applications, then the execution data of these resident applications are all stored in the same “resident” part of the volatile RAM memory. When this "resident" part is full, the execution data relating to secondary tasks of the resident applications are moved to the non-volatile working memory WM.

Additionally, if all of the secure element's resident applications are disabled, the "resident" portion of volatile RAM, which is reserved for resident application execution data, can be used to store execution data for Other Secure Element Applications. Furthermore, the size of the "resident" part of the volatile RAM memory can be adjusted according to the needs of the resident applications. Furthermore, if a resident application, which requests to be executed, does not have enough room to load its data into the "resident" part of the volatile RAM, its execution is suspended and it remains in the disabled state. The application concerned can only be executed when there is enough space in the "resident" part of the volatile RAM memory. For example, space can be freed up by disabling other resident applications. According to another example, the size of the "resident" part of the volatile memory PRAM can be increased.

According to another embodiment, the execution data of an inactive or standby application which are stored in the working memory WM are transferred to volatile memory, during a new activation of this application, only as and as required by the application. This action is performed by the low-level operating system and is transparent to the application and the corresponding high-level operating system. Indeed, data movements between volatile memory and non-volatile working memory and vice versa are not seen by high-level operating systems. In the event that all the volatile memory needs to be used during a load, the low-level operating system first moves, to the working memory, a piece of execution data which is considered to be the oldest. (the one that has been used least recently) or the least used.

Various embodiments, aspects and variations have been described. Those skilled in the art will understand that certain features of these various embodiments, aspects and variations could be combined, and other variations will occur to those skilled in the art.

In particular, the use of the non-volatile working memory has above all been described with the execution of two applications but, in practice, this use can be transposed with the use of more than two applications.

Additionally, an application could be divided into one or more resident sub-applications and one or more non-resident sub-applications. In other words, the resident application could be part of another application.

Finally, the practical implementation of the embodiments and variants described is within the abilities of those skilled in the art based on the functional indications given above.

Claims (17)

Embedded electronic system (E) comprising:
- at least one volatile memory (12, RAM); And
- at least one low-level operating system (113) managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications (App30, App31; App50, App51),
wherein said volatile memory includes:
at least a first part (PRAM30; PRAM50) reserved for execution data of a first application (App30; App50); And
at least a second part intended to store execution data of at least a second application (App31; App51),
the execution data of the first application remaining in the volatile memory in the event of deactivation or standby of this first application. Method implemented by an on-board electronic system (E) comprising:
- at least one volatile memory (12, RAM); And
- at least one low-level operating system (113) managing the allocation of volatile memory areas to several high-level operating systems each comprising one or more applications (App30, App31; App50, App51),
wherein said volatile memory includes:
at least a first part (PRAM30; PRAM50) reserved for execution data of a first application (App30; App50); And
at least a second part intended to store execution data of at least a second application (App31; App51),
the execution data of the first application remaining in the volatile memory in the event of deactivation or standby of this first application. Method according to claim 2, in which the execution data of several applications are simultaneously present in volatile memory (12). A method as claimed in claim 2 or 3, wherein a memory management function or unit (115) performed by the low-level operating system prevents access of runtime data of one application to other applications. Method according to claim 4, in which the memory management function or unit adapts the size of the first and second portions of the volatile memory according to the needs of the different applications. Method according to any one of Claims 2 to 5, in which data for the execution of one or more tasks of an application are transferred, in whole or in part, by the low-level operating system, from said volatile memory (12) to a non-volatile memory (13, WM) when the execution of said task is interrupted by the execution of at least one task of another application. Method according to claim 6, in which the non-volatile memory is external to the on-board electronic system. A method according to claim 7, wherein an application execution code is transferred to volatile memory (12) for execution. Method according to claim 6, in which the non-volatile memory is internal to the on-board electronic system. Method according to claim 9, in which an application's execution code remains in non-volatile memory (13) during the execution of a task. A method as claimed in any one of claims 6 to 10, wherein an area of non-volatile memory allocated to a high-level operating system is viewed by it as volatile working memory. A method according to any one of claims 6 to 10, wherein the high level operating systems maintain a virtual image of the memories in which the volatile and non-volatile memories are one. Method according to any one of Claims 6 to 10, in which a volatile memory area is allocated to the second application while it is not being executed, the execution data of this second application being transferred to non-volatile memory if the available volatile memory size is not sufficient for the execution of a third application. Method according to any one of Claims 2 to 13, in which, during its execution, a main task of an application is allocated an area of volatile memory. Method according to any one of Claims 2 to 14, in which the applications of a high-level operating system do not have access to the areas of the volatile memory allocated to the applications of another high-level operating system. level. System according to claim 1, configured for the implementation of the method according to any one of claims 2 to 15 On-board secure element, configured for implementing the method according to any one of Claims 2 to 15.