JP2009251967A - Multicore system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to dynamically change the access authority of each core to a memory-protecting area while keeping high security. <P>SOLUTION: A multicore system includes: an access setting information part which holds information on the access authority of each core to a memory-protecting area; a memory-protecting part which restricts or permits the access of each core to the memory-protecting area in accordance with the access setting information held by the access setting information part; a protection management part which changes the access setting information held in the access setting information part; and a non-changing information holding part which holds prescribed identification information. The access setting information part permits the access of the protection management part to the access setting information, when identification information from the protection management part matches the prescribed identification information in the non-changing information holding part, and restricts the access of the protection management part to the access setting information when the identification information from the protection management part does not match the prescribed identification information. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a multi-core system including a plurality of cores that execute two or more types of software and a memory shared by the plurality of cores.

Conventionally, when address setting and write prohibition of a write prohibition area are set between a processor and a read / write enable memory, the memory address from the processor is monitored by an address bus, and when the address becomes a write prohibition address, the processor By setting the write protection signal as the write prohibition signal and setting the write prohibition release, a memory protection circuit is provided to release the write prohibition, and by setting the address of the write prohibition area and setting the write prohibition and release in the memory protection circuit A memory protection method is known in which a write prohibition area is set in a write / readable memory, and the set area is set as a write prohibition area during a period from prohibition setting to release setting (for example, Patent Document 1). reference).
JP-A-5-113933

  However, the memory protection method described in Patent Document 1 is a method related to a system using a single processor core, and security when changing the memory protection area is not considered. In a multi-core system, the nature of the software assigned to each core differs due to the fact that multiple cores execute different types of software, and accordingly, the memory corresponding to the nature of the software executed by each core is different. The area must be allocated, and there is a situation that is greatly different from a system using a single processor core. Further, when security is not considered, there is a problem that the memory protection area can be freely changed by a malicious program or the like.

  Therefore, an object of the present invention is to make it possible to dynamically change the access authority of each core to a memory protection area while maintaining high security in a multi-core system.

In order to achieve the above object, a first invention is a multi-core system comprising a plurality of cores that execute two or more types of software and a memory shared by the plurality of cores,
An access setting information section for holding information on access authority of each core to the protected area of the memory;
A memory protection unit that restricts or permits access to the protection area of the memory by each core according to the access setting information held in the access setting information unit;
A protection management unit for changing the access setting information held in the access setting information unit;
An invariant information holding unit for holding given identification information;
The access setting information unit permits the protection management unit access to the access setting information when the identification information from the protection management unit corresponds to given identification information in the invariant information holding unit, When the identification information from the protection management unit does not correspond to the given identification information in the invariant information holding unit, the access of the protection management unit to the access setting information is restricted.

A second invention is the multi-core system according to the first invention, wherein
The two or more software includes first software and second software having higher importance (required reliability is higher) than the first software,
When the type of software executed by a specific core among the plurality of cores is changed from the first software to the second software, the protection management unit The access setting information is changed so that access to the protected area is permitted.

A third invention is the multi-core system according to the first invention, wherein
The given identification information is ID information mounted on a hardware circuit and unique to the protection management unit.

A fourth invention is the multi-core system according to the first invention, wherein
The invariant information holding unit further holds information for determining a priority order of cores that operate the protection management unit among a plurality of cores.

A fifth invention is the multi-core system according to the first invention, wherein
The two or more software includes vehicle control system software related to vehicle control and multimedia software other than vehicle control,
The plurality of cores include a first core that always executes the vehicle control system software, and a second core that executes the multimedia software,
The access setting information includes information that permits access to the protection area of the memory by the first core, while including information that restricts access to the protection area of the memory by the second core,
The protection management unit may change the access setting information so that access to the protection area of the memory by the second core is permitted.

A sixth invention is a multi-core system according to the fifth invention, wherein
A state monitoring unit for monitoring the state of the first core;
A load adjustment unit that requests the protection management unit to change the access setting information when the state monitoring unit detects a high load state or a failure state of the first core; And

A seventh invention is the multi-core system according to the sixth invention, wherein
The load adjustment unit is configured to change the access control information so that the protection management unit is permitted to access the protection area of the memory by the second core. The responsibilities of at least some of the tasks are changed from the first core to the second core.

An eighth invention is the multi-core system according to the first invention, wherein
The information processing apparatus may further include a status storage unit that stores a status when the access setting information is changed by the protection management unit.

A ninth invention is the multi-core system according to the sixth invention, wherein
The state monitoring unit requests the protection management unit to change the access setting information when a state stored in the state storage unit is detected.

  The tenth invention is characterized by a multi-core system used for constructing an in-vehicle system.

  According to the present invention, in a multi-core system, it is possible to dynamically change the access authority of each core to the memory protection area while maintaining high security.

  The best mode for carrying out the present invention will be described below with reference to the drawings.

  FIG. 1 is a diagram showing a main configuration of a multi-core system 100 according to the first embodiment of the present invention. In FIG. 1, a section 102 indicates a functional unit realized by software, and a section 104 indicates a hardware configuration.

  The multi-core system 100 of this embodiment includes a plurality of processor cores (CPUs), a dynamic memory protection control unit 10, a memory protection mechanism 30, and a main memory 32 as a hardware configuration. The illustrated multi-core system 100 includes N processor cores (core 1, core 2, core 3,..., Core N). The number N of cores is arbitrary as long as it is an integer of 2 or more. The plurality of processor cores are classified into a core that executes only a highly reliable OS described later and a core that executes only a normal OS described later in principle. However, in principle, a core that executes only a normal OS includes a core that exceptionally executes a highly reliable OS only in a predetermined case as described later.

  The dynamic memory protection control unit 10 includes an access setting information unit 11 and an invariant information holding unit 12. The access setting information unit 11 is an access setting information area for storing information on the memory protection range, and has an internal configuration including a setting register as shown in FIG. 2 and a setting table as shown in FIG. The setting register includes a special key register in which a magic number is written and an area setting register. The contents written in the area setting register are reflected in the setting table on condition that the magic number described later can be verified. In the setting table, for example, as shown in FIG. 3, an accessible area in the main memory 32 is set for each ID of the CPU (core). The access setting information in this setting table is referred to by the memory protection mechanism 30 for dynamic switching of the memory protection range described later. From the viewpoint of security assurance, only the protection management unit 23 described later holds the address information of the setting register, and only the protection management unit 23 described later can access the setting register.

  The accessible area of each core may be different for each core, or a part or all of them may overlap. However, an accessible area related to a core that executes only a high-reliability OS described later is set to be at least partially different from an accessible area related to a core that executes only a normal OS described later. This is to prevent the execution of the highly reliable OS from being hindered by the execution of the normal OS. Hereinafter, a memory area that can be accessed only by a core that executes only a highly reliable OS is also referred to as a “memory protection area”.

  FIG. 4 shows an example of a processing flow when changing the access setting information (memory protection area) in the access setting information unit 11.

  In step 001, the protection management unit 23 writes a given magic number in the special key register of the access setting information unit 11 when changing the access setting information.

  In step 002, the hardware circuit of the access setting information unit 11 determines whether or not the written magic number matches the key mounted on the hardware circuit. That is, the protection management unit 23 writes its own ID (magic number) in the register, and the hardware circuit of the access setting information unit 11 indicates that the ID written by the protection management unit 23 is the same as that of the invariant information holding unit 12. It is determined whether or not it matches the invariant information (ID information that uniquely identifies the protection management unit 23).

  In step 003, the setting table is unlocked only when the written magic number matches the key mounted on the hardware circuit. If the magic number does not match the key mounted on the hardware circuit, the setting table lock is not released and the access setting information change process results in an error.

  In step 004, the protection management unit 23 writes a setting value indicating which CPU can access which memory area in the area setting register. This written content is reflected in the data of the setting table that is unlocked. That is, the setting table data (access setting information) is changed according to the contents written by the protection management unit 23.

  In step 005, after the access setting information changing process is completed, the setting table is locked. If the access setting information is changed again, the procedure from step 001 to step 005 is repeated.

  Returning to FIG. The immutable information holding unit 12 holds information that cannot be changed by software. In other words, the invariant information holding unit 12 is an unmodifiable area on the hardware circuit in which predetermined information (invariant information) is embedded. The immutable information holding unit 12 is set in order to prevent the occurrence of security holes that may occur as a result of enabling the access setting information changing process as described above. Specifically, the invariant information held in the invariant information holding unit 12 includes ID information (the above-mentioned magic number) that uniquely identifies the protection management unit 23, the priority order of the core number that operates the protection management unit 23, and the like. May be included. These invariant information is information for preventing access to the access setting information unit 11 due to malicious programs or software bugs. The reason for including the priority order of the core numbers for operating the protection management unit 23 is that, even if the core operating the protection management unit 23 stops operating due to a hardware failure or the like, This is because the protection management unit 23 can be newly activated on a core having a higher priority.

  When the memory protection mechanism 30 receives an access request to the main memory 32 from any of the plurality of cores 1, core 2, core 3,..., Core N, the setting table of the access setting information unit 11 The access request to the main memory 32 by the core is restricted / permitted according to the data of For example, in the case of the setting table data shown in FIG. 3, when the core 2 issues a write request to the address number 0x4000_0000 of the main memory 32, the address number 0x4000_0000 is not an accessible area for the core 2, so the write request is restricted. (Rejected).

  The main memory 32 is a main storage device shared by a plurality of cores 1, cores 2, cores 3,..., Core N. For example, volatile storage that electrically stores data using semiconductor elements. Device. The main memory 32 may be composed of a plurality of memories.

  In the multi-core system 100 of this embodiment, two types of software programs, a highly reliable OS and a normal OS, are roughly executed by a plurality of cores 1, a core 2, a core 3,. The high-reliability OS is required high-reliability software, and in the vehicle system, it is software related to vehicle control (for example, vehicle control system software such as ABS, follow-up running control system, braking force control system, etc.). It's okay. On the other hand, a normal OS is software that is not as highly reliable as a highly reliable OS, and software that is not directly related to vehicle control, such as software related to convenience (for example, navigation systems and information search systems). Multimedia software).

  In principle, the cores that execute the high-reliability OS and the normal OS are predetermined. However, as described later, in a predetermined case such as when a high-load state is detected on the high-reliability OS side, the access setting information is stored. In cooperation with the change, at least one of the cores that normally execute the OS is transferred to the highly reliable OS so as to execute the highly reliable OS.

  The multi-core system 100 includes an in-OS processing management unit 20 as its main software function unit. In addition, the multi-core system 100 includes a plurality of OS controls and inter-OS communication functions. The in-OS processing management unit 20 includes a load adjustment unit 21 and a state monitoring unit 22 that function in a highly reliable area, and a protection management unit 23, and also includes a load adjustment unit 24 and a state monitoring unit 25 that function in a normal area.

  The load adjustment unit 21 is a part that adjusts the load between the cores accompanying the change of the access setting information. The load adjusting unit 21 receives the notification of the monitoring result of the load state from the state monitoring unit 22 and determines whether or not the load adjustment is necessary. As the determination content, for example, the following logic can be considered. First, it is determined whether or not task processing is possible in the highly reliable OS. This may be determined based on the current load state, the assumed duration of the load state, and the like. If it is determined that task processing is possible within the highly reliable OS, it is determined that load adjustment is unnecessary. On the other hand, if it is determined that task processing is impossible in the high-reliability OS, a task that can be suspended or stopped from the task priority information (known setting value) among the high-reliability OS-side tasks. By extracting and suspending or stopping the extracted task, it is determined whether or not task processing can be performed in the highly reliable OS. If it is determined that task processing can be performed in the highly reliable OS by suspending or stopping the extracted task, it is determined that load adjustment is unnecessary. On the other hand, even if the extracted task is suspended or stopped, if it is determined that the task processing is impossible in the high-reliable OS, the access setting information is changed to increase the core used by the high-reliable OS. Move to the procedure. In other words, the load adjustment unit 21 requests the protection management unit 23 to change the access setting information (request to increase the use core of the highly reliable OS). When the load adjustment unit 21 receives a notification from the protection management unit 23 indicating that the number of used cores has been increased, the load adjustment unit 21 includes the new cores related to the increase notification based on the monitoring result of the load state by the state monitoring unit 22. Adjustment is performed to eliminate the state in which task processing is impossible in the above-described highly reliable OS. For example, by assigning a task process that cannot be processed in the high-reliability OS to a new core related to the increase notification, the state in which the task process cannot be performed in the high-reliable OS is solved. At this time, the tasks extracted for suspending or stopping may also be executed using the increased core on the highly reliable OS side.

  The state monitor unit 22 is a part that monitors the load and malfunction of each core in the highly reliable OS. The state monitor unit 22 monitors statistical data such as the CPU load rate and memory usage rate, which are management information of the OS, and when a high load or a hardware failure state is detected, the state monitor unit 22 notifies the load adjustment unit 21 of that fact. Notice. For example, the state monitor unit 22 may detect a high load state when the CPU usage rate of the core executing the highly reliable OS exceeds 70%. Further, the state monitor unit 22 may detect a hardware failure state when, for example, an alarm indicating a failure of a core executing a highly reliable OS occurs.

  The protection management unit 23 is a main part that changes the access setting information as described above, and accesses the access information setting unit 11 in response to a request from the load adjustment unit 21. In addition, as a cooperation function with the load adjustment unit 24 on the normal OS side, it has a core use request function and a core transfer completion notification receiving function. Refer to the sequence shown in FIG. 5 for this.

  The load adjusting unit 24 is a part that adjusts the load between the cores in the normal OS based on the monitoring result of the load state by the state monitoring unit 25. In addition, the load adjustment unit 24 notifies the protection management unit 23 of the core transfer completion when the adjustment for transferring the core to the highly reliable OS side is completed.

  The state monitor unit 25 is a part that monitors the load and malfunction of each core on the normal OS side.

  FIG. 5 is a diagram illustrating a processing sequence when a high load state occurs in the multi-core system 100 according to the first embodiment. Here, as an example, the multi-core system 100 includes four cores 1, 2, 3, and 4, and as a default setting, the core 1 and the core 2 are in a normal state (that is, in the occurrence of a high load state described later). It is assumed that the cores 3 and 4 are set as the cores used for the normal OS at the normal time. Accordingly, in the setting table of the access setting information unit 11, an area accessible only by the core 1 and the core 2 (that is, a memory protection area inaccessible by the core 3 and the core 4) is set as a default setting. It is assumed that

  Referring to FIG. 5 in time series, first, when a high load state occurs on the highly reliable OS side, the state monitor unit 22 detects the high load state. For example, as shown in part C of FIG. 5, the tasks to be executed by the cores 1 and 2 are the tasks U, V, W, X, Y, and Z, and the tasks U and X cannot be processed within a predetermined time. In some cases, a high load condition is detected. When a high load state is detected, the load adjustment unit 21 on the high reliability OS side is notified, and the load adjustment unit 21 determines whether or not the number of cores used by the high reliability OS should be increased as described above. When it is determined that the number of used cores of the highly reliable OS should be increased, a request to that effect (request for changing the number of used cores) is made to the protection management unit 23. The protection management unit 23 accepts this request and makes a use request in the high-reliability OS of the core used by the normal OS (for example, the core 3) to the load adjustment unit 24 on the normal OS side. The load adjustment unit 24 on the normal OS side receives this request and requests the status monitor unit 25 on the normal OS side to acquire operation information of each task on the normal OS. The state monitor unit 25 on the normal OS side receives this request, acquires operation information of each task on the normal OS, and supplies the operation information to the load adjustment unit 24. The load adjustment unit 24 acquires operation information of each task on the normal OS from the state monitor unit 25, and performs task movement in consideration of the acquired information. For example, the load adjustment unit 24 on the normal OS side moves the tasks a and b of the core 3 to the core 4 as shown in part A of FIG. As a result, the core 3 can be used with a highly reliable OS. Here, with the reduction in the number of cores used on the normal OS side, there is a possibility that not all tasks can be moved depending on the load state on the normal OS side. In that case, the task to be moved and the task to be ended may be determined according to the priority of the task. When the task movement is completed, a notification to that effect (movement completion notification) is sent to the protection management unit 23, and the protection management unit 23 changes the access setting information upon receiving this notification. For example, as shown in part B of FIG. 5, when the task transfer completion notification of the core 3 is received, the access setting information part 11 is accessed so that the core 3 can access the memory protection area. The access authority for the protection area is changed from cores 1 to 2 to cores 1 to 3. When the access setting information is changed in this way, the protection management unit 23 notifies the load adjustment unit 21 on the highly reliable OS side of an increase in usable cores as a core transfer completion notification. Upon receiving this notification, the load adjustment unit 21 on the high-reliability OS side requests the state monitor unit 22 on the high-reliability OS side to obtain operation information of each task on the high-reliability OS. The state monitor unit 22 on the highly reliable OS side receives this request, acquires operation information of each task on the highly reliable OS, and supplies the operation information to the load adjustment unit 21 on the highly reliable OS side. The load adjustment unit 21 on the high-reliability OS side acquires operation information of each task on the high-reliability OS from the state monitor unit 22, and performs task movement in consideration of the acquired information. For example, the load adjustment unit 21 on the highly reliable OS side moves the tasks U and X of the core 1 and the core 2 to the new core 3 as illustrated in part C of FIG. In this case, the core 3 uses the memory protection area of the main memory 32 to execute the tasks U and X on the highly reliable OS side. In this way, even when the highly reliable OS cores 1 and 2 fall into a high load state and the tasks U and X of the highly reliable OS cannot be processed, the normal OS side core 3 is used, The tasks U and X of the high-reliability OS can be executed in the memory protection area of the main memory 32.

  In the processing sequence shown in FIG. 5, the detected high load state is eliminated, and the loads on the cores 1 and 2 on the highly reliable OS side are reduced to a predetermined level or less based on the monitoring result of the state monitor unit 22. In the case (when returning to the normal load state or the low load state), the protection management unit 23 accesses the access setting information unit 11 and changes the core access authority to the memory protection area from the cores 1 to 3 to the core 1. Change to ~ 2 (revert). Alternatively, in the processing sequence shown in FIG. 5, when the core 3 has finished executing the tasks U and X, the protection management unit 23 accesses the access setting information unit 11 to access the core to the memory protection area. May be changed from cores 1 to 3 to cores 1 and 2.

  FIG. 6 is a diagram illustrating a processing sequence when a malfunction state occurs in the multi-core system 100 according to the first embodiment. The processing sequence of FIG. 6 detects a hardware failure state on the high-reliability OS side instead of detecting a high-load state on the high-reliability OS side with respect to the processing sequence shown in FIG. The only difference is that this is triggered.

  According to the processing sequence shown in FIG. 6, for example, as shown in part C of FIG. 6, even when the core 2 on the highly reliable OS side becomes inoperable and the tasks U and X of the core 2 become incapable of processing, By using the core 3 on the normal OS side, the tasks U and X of the highly reliable OS can be executed in the memory protection area of the main memory 32.

  By the way, in recent in-vehicle systems, a system (multi-core system) equipped with a plurality of cores 1 to N as described above is desired because of improvement in processing performance due to diversification of services to be realized and demand for heat countermeasures peculiar to in-vehicle environments. There is a need for a system 100). Further, it is required that vehicle control system software for controlling a vehicle and multimedia software for realizing an evolving multimedia service are installed on the same system. In such a system in which the vehicle control system and the multimedia system coexist, a memory protection function is indispensable in order to protect the quality and reliability of the system.

  In this regard, according to the present embodiment, as described above, the quality and reliability of the system related to the highly reliable OS can be protected by setting the memory protection area accessible only by the core on the highly reliable OS side. .

  Also, from the viewpoint of limited CPU resources, it is not possible to allocate unlimited CPU resources to a highly reliable OS. Therefore, there may occur a case where the core in charge of the highly reliable OS falls into a high load state and the task of the highly reliable OS becomes unprocessable. In such a case, it is possible to temporarily execute the highly reliable OS by using the core on the normal OS side. However, a high-reliability OS needs to ensure high quality and reliability, but it is necessary because the accessible area of the core on the normal OS side is insufficient if it is simply executed by the core on the normal OS side. In some cases, high quality and reliability cannot be ensured. This is the same not only when the core in charge of the high-reliability OS falls into a high load state, but also when the core in charge of the high-reliability OS falls into a malfunctioning state.

  In this regard, according to the present embodiment, as described above, even when the core in charge of the high-reliability OS falls into a high load state or a failure state, the core on the normal OS side performs the task of the high-reliability OS in the memory protection area. Since it can be executed, CPU resources can be efficiently used while ensuring the required high quality and reliability required for a highly reliable OS. Thereby, the vehicle-mounted system which can coexist a vehicle control system and a multimedia system effectively can be constructed | assembled.

  Further, according to the present embodiment, as described above, the change of the access setting information in the access setting information unit 11 can be executed only when the collation by the key held in the invariant information holding unit 12 is confirmed. High security can be maintained. In addition, the key held by the invariant information holding unit 12 is invariant information embedded in the hardware circuit, and is a key that is not known to the user, so that high security is maintained. The key held by the invariant information holding unit 12 is invariant information embedded in the hardware circuit and is not rewritten by malicious software, so that high security is maintained.

  FIG. 7 is a diagram showing a main configuration of a multi-core system 200 according to the second embodiment of the present invention. In FIG. 7, a section 202 indicates a functional unit realized by software, and a section 104 indicates a hardware configuration. The hardware configuration may be the same as that of the first embodiment, and detailed description thereof is omitted.

  The multi-core system 200 according to the present embodiment is mainly different from the above-described first embodiment in that a situation storage unit 26 and a prediction / learning unit 27 are additionally provided in the in-OS processing management unit 22 ′. . The situation storage unit 26 is provided in both the high reliability area and the normal area, and the prediction / learning unit 27 is provided in the high reliability area.

  The situation storage unit 26 is a part that stores the situation where the access setting information is changed. Specifically, the status storage unit 26 generates a situation in the multi-core system 200 when an event that changes access setting information (for example, the above-described high load state), for example, an occurrence time of an event that changes access setting information. And operating tasks, OS statistical information (utilization rate of cores, buses, etc.) and the like are stored. Alternatively, the situation storage unit 26 may be configured to provide a situation outside the multi-core system 200 when an event that changes access setting information occurs, for example, the position of the vehicle or the surrounding environment (roads) when an event that changes access setting information occurs. Or temperature), the running state of the vehicle (speed, acceleration, etc.), etc. may be stored. In this case, these pieces of information may be generated based on the situation detected by the in-vehicle sensor (including the in-vehicle camera).

  The prediction / learning unit 27 is a pattern of occurrence of a high load or a hardware failure in which the access setting information is changed as described above from the data stored in the status storage unit 26 on both the reliable OS side and the normal OS side. It has a function to analyze Further, when the prediction / learning unit 27 detects the occurrence of a precursor pattern that is predicted to cause a high load or hardware failure based on the analysis result, the prediction / learning unit 27 notifies the protection management unit 23 to that effect. . Note that the prediction / learning unit 27 operates only in the high reliability area as described above.

  The prediction / learning unit 27, for example, based on the data stored in the situation storage unit 26, a bias for each event occurrence time that changes the access setting information, a bias due to an operation application, a bias due to a hardware usage rate, a hardware Analyze and extract patterns such as the bias of defects by wear type.

  FIG. 8 is a diagram illustrating a processing sequence when a high load / failure state occurs in the multi-core system 200 according to the second embodiment. The processing sequence shown in FIG. 8 is mainly different from the processing sequence shown in FIG. 5 and the like described above in that processing by the situation storage unit 26 and the prediction / learning unit 27 is added.

  In the processing sequence shown in FIG. 8, when a high load / failure state occurs, the situation at that time is stored in the situation storage unit 26, and the condition of the situation where the high load / failure state occurs is analyzed / predicted by the prediction / learning unit 27. Extracted. When the condition of a situation in which a high load / failure state occurs is analyzed by the prediction / learning unit 27, the condition is added as a monitoring condition and notified to the state monitoring unit 22. When the monitoring condition is notified, the state monitoring unit 22 performs a determination process as to whether or not a situation corresponding to the monitoring condition is detected, in addition to the detection process of the high load / failure state, and corresponds to the monitoring condition. When the situation is detected, a request for changing the number of used cores is made to the protection management unit 23.

  For example, as shown in part C of FIG. 8, when a situation in which the tasks to be executed by the cores 1 and 2 are predicted to be tasks U, V, W, X, Y, and Z is used in advance. A request for changing the number of cores is notified to the protection management unit 23, and a state is formed in which the core 3 can execute the tasks U and X on the highly reliable OS side using the memory protection area of the main memory 32.

  As described above, according to the second embodiment, when a monitoring condition is added, when a situation corresponding to the monitoring condition is detected, a request for changing the number of used cores is immediately issued to the protection management unit 23. Compared with the case where a request for changing the number of used cores is sent to the protection management unit 23 via the unit 21, the response time can be shortened. That is, the access setting information can be changed before a high load / failure state occurs, and the memory of the main memory 32 is protected using the core on the normal OS side even when the high load / failure state occurs. A highly reliable OS can be executed in the area. The second embodiment that realizes such an improvement in responsiveness is suitable for an in-vehicle system that requires quick responsiveness.

  The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the above-described embodiments, and various modifications and substitutions can be made to the above-described embodiments without departing from the scope of the present invention. Can be added.

  For example, in the above-described embodiment, the memory protection area is substantially changed by changing the access authority of the core on the normal OS side to the memory protection area when a high load / failure state occurs. In addition, the memory protection area itself may be increased when a high load / failure state occurs. For example, when a high load / failure state occurs, a memory area that is not normally used or a memory area that is normally used by the core on the OS side may be additionally set as a memory protection area. In the latter case (when a memory area that is normally accessible by the core on the OS side is added as a memory protection area when a high load / failure state occurs), change the access setting information in the setting table to Only the core on the high-reliability OS side and the core transferred to the high-reliability OS side are accessible to the added memory protection area, and the other cores on the normal OS side are not accessible.

It is a figure which shows the main structures of the multi-core system 100 by Example 1 of this invention. It is a figure which shows an example of a setting register. It is a figure which shows an example of the data of a setting table. It is a figure which shows an example of the processing flow at the time of changing the access setting information (memory protection area) in the access setting information part. It is a figure which shows the process sequence at the time of the high load state occurrence in the multi-core system 100 by Example 1. FIG. It is a figure which shows the process sequence at the time of the malfunction state in the multi-core system 100 by Example 1. FIG. It is a figure which shows the main structures of the multi-core system 200 by Example 2 of this invention. It is a figure which shows the processing sequence at the time of the high load / failure state occurrence in the multi-core system 200 according to the second embodiment.

Explanation of symbols

1-N Core 10 Dynamic Memory Protection Control Unit 11 Access Setting Information Unit 12 Invariant Information Holding Unit 20 In-OS Process Management Unit 21 Load Adjustment Unit 22, 22 ′ Status Monitor Unit 23 Protection Management Unit 24 Load Adjustment Unit 25 Status Monitor Unit 26 Situation Saving Unit 27 Prediction / Learning Unit 30 Memory Protection Mechanism 32 Main Memory 100, 200 Multicore System 102, 202 Software Section 104 Hardware Section

Claims (10)

A multi-core system comprising a plurality of cores that execute two or more different types of software and a memory shared by the plurality of cores,
An access setting information section for holding information on access authority of each core to the protected area of the memory;
A memory protection unit that restricts or permits access to the protection area of the memory by each core according to the access setting information held in the access setting information unit;
A protection management unit for changing the access setting information held in the access setting information unit;
An invariant information holding unit for holding given identification information;
The access setting information unit permits the protection management unit to access the access setting information when the identification information from the protection management unit corresponds to given identification information in the invariant information holding unit, A multi-core system that restricts access of the protection management unit to the access setting information when identification information from a protection management unit does not correspond to given identification information in the invariant information holding unit. The two or more software includes first software and second software having higher importance than the first software,
When the type of software executed by a specific core among the plurality of cores is changed from the first software to the second software, the protection management unit The multi-core system according to claim 1, wherein the access setting information is changed so that access to the protected area is permitted.   The multi-core system according to claim 1, wherein the given identification information is ID information mounted on a hardware circuit and unique to the protection management unit.   The multi-core system according to claim 1, wherein the invariant information holding unit further holds information for determining a priority order of cores that operate the protection management unit among a plurality of cores. The two or more software includes vehicle control system software related to vehicle control and multimedia software other than vehicle control,
The plurality of cores include a first core that always executes the vehicle control system software, and a second core that executes the multimedia software,
The access setting information includes information that permits access to the protection area of the memory by the first core, while including information that restricts access to the protection area of the memory by the second core,
The multi-core system according to claim 1, wherein the protection management unit changes the access setting information so that access to the protected area of the memory by the second core is permitted. A state monitoring unit for monitoring the state of the first core;
A load adjustment unit that requests the protection management unit to change the access setting information when the state monitoring unit detects a high load state or a malfunction state of the first core. 5. The multi-core system according to 5.   The load adjustment unit is configured to change the access control information so that the protection management unit is permitted to access the protection area of the memory by the second core. The multi-core system according to claim 6, wherein responsibility for at least some of the tasks is changed from the first core to the second core.   The multi-core system according to claim 1, further comprising a status storage unit that stores a status when the access setting information is changed by the protection management unit.   The multi-core system according to claim 6, wherein the state monitoring unit requests the protection management unit to change the access setting information when a state stored in the state storage unit is detected.   The multi-core system according to claim 1, which realizes an in-vehicle system.

Images