Function allocation system
Patent Information
- Application Number
- JP2024014607
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-02-02
- Publication Date
- 2026-09-01
AI Technical Summary
Current development methodologies for systems with multiple chips result in inconsistent system consistency until integration testing, leading to increased development costs, time, and potential operational non-conformance with specifications.
An allocation system that allocates application programs to hardware and middleware using a computer with an arithmetic unit, input unit, allocation processing unit, and output unit, based on input specifications and indices, to optimize chip and middleware combinations.
Enables efficient use of chip performance by ensuring system configurations meet specifications, reducing development costs and time, and enhancing operational conformity.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a function allocation system. [Background technology]
[0002] In current solution development, applications to be installed on different chips are developed in parallel and separately.
[0003] The following prior art exists as background art in this technical field: Patent Document 1 (JP 2010-39677 A) describes a design support device comprising: an acquisition means for acquiring an architecture consisting of a group of hardware models that execute software, a determination means for determining the possibility of dividing and / or merging hardware models in the architecture acquired by the acquisition means, a reconstruction means for reconstructing the architecture based on the determination result made by the determination means, and an output means for outputting the architecture after reconstructing by the reconstruction means. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-39677 Summary of the Invention [Problem to be solved by the invention]
[0005] With the parallel and separated development methodology described above, system consistency cannot be confirmed until development integration testing, and frequent adjustments between development processes occur, which increases development costs due to an increase in development personnel and development time, reducing solution cost competitiveness and increasing losses.
[0006] Furthermore, the operation of the entire device in which the application is implemented may not conform to specifications such as operation, rating, and cost.
[0007] An object of the present invention is to provide a platform for quickly designing a system in which multiple chips with different functions work together to achieve a single purpose. [Means for solving the problem]
[0008] A representative example of the invention disclosed in the present application is as follows: That is, an allocation system for allocating an application program to hardware and middleware, comprising a computer having an arithmetic unit that executes predetermined arithmetic processing and a storage device connected to the arithmetic unit, wherein the arithmetic unit has an input unit that receives a designation of an index, an allocation processing unit that allocates a combination of a chip virtual model and a middleware virtual model recorded in a database and an operation mode of each virtual model based on an input application specification and the index received by the input unit, and an output unit that outputs a result of the allocation by the allocation processing unit. [Effects of the Invention]
[0009] According to one aspect of the present invention, it is possible to efficiently use the performance of the chips that make up a system in which multiple chips with different functions work together to achieve a single purpose. Problems, configurations, and effects other than those described above will become apparent from the following description of the preferred embodiment of the present invention. [Brief explanation of the drawings]
[0010] [Figure 1] 1 is a block diagram showing a configuration of an application function allocation system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a diagram illustrating an example of a screen of a user interface according to the present embodiment. [Figure 3] 1 is a block diagram showing a configuration of a function allocation system according to an embodiment of the present invention; [Figure 4] 10 is a flowchart of a process executed by a function allocation system in an application code development operation according to the present embodiment. [Figure 5]FIG. 10 is a diagram showing an example of a method for creating a system / chip configuration diagram to be input to the application function allocation system. [Figure 6] FIG. 2 is a diagram illustrating inputs and outputs of a system virtual model according to the present embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of the configuration of performance (processing time) data according to the present embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of the configuration of performance (power consumption) data according to the present embodiment. [Figure 9] FIG. 2 is a diagram illustrating an example of the configuration of performance (cost) data according to the present embodiment. [Figure 10] 10 is a flowchart of a process executed by a chip-middle allocation function of the present embodiment. [Figure 11] 10 is a flowchart of a process executed by application software of the multimodal sensing system of the present embodiment. [Figure 12] FIG. 1 is a diagram illustrating an example of a system hardware configuration and divided functions of a multimodal sensing system according to an embodiment of the present invention. [Figure 13] 4 is a flowchart of a process executed by application software of the vibration diagnosis system of the present embodiment. [Figure 14] 1 is a diagram illustrating an example of a hardware configuration of a vibration diagnosis system according to an embodiment of the present invention and functions that are executed by dividing the hardware configuration; [Figure 15] 10 is a flowchart of a process executed by application software of the device key authentication system according to the present embodiment. [Figure 16] 1 is a diagram illustrating an example of a hardware configuration of a device key authentication system according to an embodiment of the present invention and functions that are executed in a divided manner. DETAILED DESCRIPTION OF THE INVENTION
[0011] Example 1 FIG. 1 is a block diagram showing the configuration of an application function allocation system 1 according to this embodiment.
[0012] The application function allocation system 1 of this embodiment includes an allocation calculation unit 50, a system virtual model unit 60, a middleware virtual model database 70, a chip virtual model database 75, and a user interface unit 80.
[0013] The allocation calculation unit 50 performs calculations to allocate application functions to middleware and hardware (chips). The middleware virtual model database 70 stores a middleware virtual model 32 that derives the performance of application functions when they are run by middleware. In this embodiment, middleware refers to software implemented on top of an in-chip OS (operating system) platform or hardware driver software. It utilizes general-purpose functions provided by the OS to provide complex intermediate processing functions to higher-level application software in the form of libraries / APIs (application programming interfaces). It is software that directly or indirectly controls a chip, including software / libraries provided by SDKs (software development kits). Furthermore, in cases such as microcontrollers and FPGAs (field-programmable gate arrays), where instructions are decoded and analyzed from a program counter using a CPU (processor) and memory / registers without an OS, and circuit operation is executed, it is software that directly controls the chip. The chip virtual model database 75 stores a chip virtual model 33 that derives the performance of application functions when they are run by hardware. The system virtual model unit 60 estimates the performance when the application functions are operated by the middleware and hardware, using the middleware virtual model 32 and the chip virtual model 33. The user interface unit 80 provides an evaluation index input unit 81 and a system configuration input unit 82 as user interfaces through which the user inputs allocation conditions, and provides a calculation result output unit 83 as a user interface that outputs the calculation results by the allocation calculation unit 50.
[0014] FIG. 2 is a diagram showing an example of a screen of a user interface provided by the user interface unit 80 of this embodiment.
[0015] The example screen shown in Figure 2 includes an evaluation index input section 81, a system configuration input section 82, and a calculation result output section 83. The evaluation index input section 81 inputs evaluation indexes corresponding to the chip type. The specific names of the computing resources, such as GPUs (graphical processing units), CPUs, and FPGAs, are input as chip types. The evaluation indexes are used as parameters for the optimization calculation. The system configuration input section 82 includes an application code workspace area and a system design workspace area. The application code workspace area is used to input the overall processing flow of the application software. This can be specified using a processing flowchart or an input interface for program code (e.g., source code with a filename of ".py" for Python code). The system design workspace area is used to input the hierarchical structure of the hardware and middleware that constitute the computer system on which the application software is implemented, i.e., chip implementation hierarchy information, the number of constituent computing resources, and computing resource information. The input format may be a drawing of a block diagram, or a text file describing the structure (e.g., JSON format ".json"). The calculation result output unit 83 displays in matrix format the performance for each evaluation index when each middleware is run on each input chip type. In addition, by specifying the index to be optimized for the entire system, a system configuration candidate that achieves the optimization index can be output as an optimal configuration candidate.
[0016] FIG. 3 is a block diagram showing the configuration of the application function allocation system 1 of this embodiment.
[0017] The application function allocation system 1 of this embodiment is configured by a computer having a processor (CPU) 10, a memory 20, a storage 30, an input / output interface 40, and a communication interface 45.
[0018] The processor 10 is a computing device that executes programs stored in the memory 20. The processor 10 executes various programs to realize various functional units (e.g., a data collection unit 11, an information processing / output unit 12, etc.) of the application function allocation system 1. Note that some of the processing performed by the processor 10 by executing the programs may be executed by other computing devices (e.g., hardware such as a GPU, ASIC, or FPGA).
[0019] The data collection unit 11 collects data for allocating application software functions to hardware and middleware. The information processing and output unit 12 has an allocation processing unit 13 and a performance visualization and analysis unit 14. The allocation processing unit 13 executes processing to allocate application software functions to hardware and middleware. The performance visualization and analysis unit 14 executes a simulation to allocate application software functions to hardware and middleware, and calculates performance when the application software functions are allocated to each of the hardware and middleware.
[0020] The memory 20 includes a ROM, which is a non-volatile storage element, and a RAM, which is a volatile storage element. The ROM stores unchanging programs (e.g., BIOS), etc. The RAM is a high-speed, volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores programs executed by the processor 10 and data used when the programs are executed.
[0021] The storage 30 is a large-capacity, non-volatile storage device such as a magnetic storage device (HDD) or a flash memory (SSD). The storage 30 also stores data (e.g., a system performance model 31, a middleware virtual model 32, a chip virtual model 33, etc.) used by the processor 10 when the processor 10 executes a program, and the program executed by the processor 10. That is, the program is read from the storage 30, loaded into the memory 20, and executed by the processor 10 to realize each function of the application function allocation system 1.
[0022] The system performance model 31 is a model that simulates the operation of a system on which application software is executed. The middleware virtual model 32 is a model that simulates the operation of middleware to which application software functions are allocated. The chip virtual model 33 is a model that simulates the operation of hardware to which application software functions are allocated.
[0023] The input / output interface 40 is an interface to which input devices such as a keyboard and a mouse are connected to receive input from an operator, and which is connected to output devices such as a display device and a printer to output the results of program execution in a format that can be viewed by the user. Note that a terminal (not shown) connected to the application function allocation system 1 via a network may provide the input / output interface. In this case, the application function allocation system 1 may have the functionality of a web server, and the terminal may access the application function allocation system 1 using a predetermined protocol (for example, http).
[0024] The communication interface 45 is a network interface device that controls communication with other devices in accordance with a predetermined protocol.
[0025] The programs executed by the processor 10 are provided to the application function allocation system 1 from removable media (such as a CD-ROM or flash memory) or via a network, and are stored in non-volatile storage 30, which is a non-transitory storage medium. For this reason, the application function allocation system 1 preferably has an interface for reading data from removable media.
[0026] The application function allocation system 1 is a computer system configured on one physical computer or on multiple logically or physically configured computers, and may operate on a virtual computer constructed on multiple physical computer resources. For example, each functional unit may operate on a separate physical or logical computer, or multiple functional units may be combined to operate on a single physical or logical computer.
[0027] FIG. 4 is a flowchart of the process executed by the application function allocation system 1 in the application code development work.
[0028] In the application code development work, first, application specifications 201 that describe the system specifications are determined. Then, application source code 202, system / chip configuration diagram 203, usage environment information 204, and evaluation index information 205 are generated from the application specifications 201 and input to the application function allocation system 1.
[0029] The application source code 202 is the source code of application software created in the application code development work. The system / chip configuration diagram 203 is a hierarchical structure of hardware and middleware that constitutes a computer system on which the application software is implemented, and is input to the system configuration input unit 82. As shown in FIG. 5, the system / chip configuration diagram 203 may be configured from location candidate information that indicates the number of computing resources that can be configured. Computing resource information may be referenced when configuring the system / chip configuration diagram 203. The usage environment information 204 is information about the environment in which the computer system on which the application software is implemented is used. The evaluation index information 205 defines evaluation indexes, which are coefficients that weight each performance, in an evaluation function described below. Therefore, the evaluation index information 205 can also be defined as priority information of evaluation indexes for optimizing the application (target system).
[0030] Figure 5 shows a specific example of system / chip data extraction from input in the system design workspace of the system configuration input unit 82 shown in Figure 2. The system / chip configuration diagram 203 is composed of location candidate information (the number of computing resources that can be constructed) and information specifying the computing resource information. By specifying information such as the number of computing resources to be deployed for data centers, cloud servers, on-premises servers, edge servers, and devices at each installation site, the type of resources (e.g., calculation performance specifications, memory capacity, storage media capacity, etc.), and communication specifications in a hierarchical structure, for example, in JSON format, it is possible to specify system topology information such as that shown in the lower diagram of Figure 5 to the application function allocation system 1, evaluate a specific system configuration, and obtain a more optimal configuration.
[0031] In the application function allocation system 1, the code analysis function 101 analyzes the input application source code 202 and sends the analysis results to the function block division function 102. For example, as shown in FIG. 6, the code analysis function 101 analyzes the core structure of the software program, such as the library (function) file structure, the internal structure of the used libraries, the sequential structure, the selection / branch structure, and the iterative structure, and records the analyzed library reference relationships and processing flows by storing them in a graph database (DB) or the like. The function block division function 102 divides the input application source code 202 according to the analysis results and sends the divided source code and the stored library reference relationships and processing flow information to the function data extraction function 103. The function data extraction function 103 extracts function data for each divided source code from the divided source code and inputs the extracted function data to the system virtual model 106. As shown in FIG. 6, the function data extracted by the function data extraction function 103 includes the relationship between the number of uses of the used libraries and functions, the relationship between the sequential structure and the number of lines, the relationship between the selection (branch) structure and the number of uses, the relationship between the iterative structure and the number of uses, and the performance evaluation results on reference hardware.
[0032] Furthermore, the system / chip data extraction function 104 extracts system HW data from the input system / chip configuration diagram 203 and inputs the extracted system HW data into the system virtual model 106. As shown in Fig. 6, the system HW data extracted by the system / chip data extraction function 104 includes system topology information, product name or model name, price data, performance specification data (e.g., CPU specifications, memory, storage unit data), public cloud (e.g., service, private cloud), and communication specifications.
[0033] Furthermore, the environmental data extraction function 105 extracts usage environment data from the input usage environment information 204 and inputs the extracted usage environment data into the system virtual model 106. The usage environment data extracted by the environmental data extraction function 105 includes the usage temperature, usage humidity, dust, and the presence or absence of water, as shown in FIG.
[0034] The performance estimation function 107 determines the performance of application usage using the middleware virtual model 32, the chip virtual model 33, and the system virtual model 106, which has input function data, system / chip data, and environmental data, and sends the performance determination result to the chip-middle allocation function 108. The middleware virtual model 32 is software that models the functional and performance behavior of various middleware and is a model constructed mainly from function data as shown in Figure 6. The middleware virtual model 32 may be a model generated deductively, or a model constructed using an empirical method such as a machine learning model. The chip virtual model 33 is software that models the functional and performance behavior of various chips and is a model constructed mainly from system / HW data and usage environment data as shown in Figure 6. The chip virtual model 33 may be a model generated deductively, or a model constructed using an empirical method such as a machine learning model. In particular, the virtual chip model 33 may be a model of the behavior of the chip based on a data sheet or the like provided by each chip vendor.
[0035] As shown in FIG. 6, the system virtual model 106 is a model that virtualizes the entire system, associating public clouds / services, private clouds, system topology information, communication specifications, and the like. The system virtual model 106 is a model that derives hardware performance data as a target variable using function data, system / HW data, and usage environment data as explanatory variables. It may be a deductively generated model, or it may be constructed using a machine learning model that has been trained using an empirical method based on the relationship between function data, system / HW data, and usage environment data and hardware performance data. Performance data derived by the system virtual model 106 includes, for example, power consumption, processing time, cost, and security level, and will be described with reference to FIGS. 7, 8, and 9.
[0036] 7 is a diagram showing an example of the configuration of performance (processing time) data. The performance (processing time) data is generated by the system virtual model 106 and records the processing time for a combination of chips and middleware. In other words, the performance (processing time) data is output in matrix format as the processing time when each piece of middleware that realizes an application input in the application (system) specification 201 is operated on each chip, which is a computing resource as a system component for realizing the application.
[0037] 8 is a diagram showing an example of the configuration of performance (power consumption) data. The performance (power consumption) data is generated by the system virtual model 106 and records the power consumption of a combination of chips and middleware. In other words, the performance (power consumption) data is an output in matrix format of the power consumption when each piece of middleware that realizes an application input in the application (system) specifications 201 is run on each chip, which is a computing resource as a system component for realizing the application.
[0038] 9 is a diagram showing an example of the configuration of performance (cost) data. The performance (cost) data is generated by the system virtual model 106, and records the price, which is the cost of the chip.
[0039] The system virtual model 106 is composed of a middleware virtual model 32 and a chip virtual model 33. The middleware virtual model 32 is a model that virtualizes middleware, and virtualizes the software code description, i.e., the input / output interface including processing performance, and contains information such as the number of times used libraries / functions, the number of lines of sequential structure, the number of times used selection (branching) structure, the number of times used repetitive structure, and the performance evaluation results on reference HW. The chip virtual model 33 is a model that virtualizes the behavior of hardware / chips, and contains information such as product name / model name, price data, and performance specification data (CPU specifications, memory, storage unit), and it inputs the processing content described by the middleware and outputs processing performance information as individual hardware.
[0040] The chip-middle allocation function 108 determines the relationship between chips and middleware based on the performance estimation results. For example, the chip-middle allocation function 108 searches for a combination of hardware and functions that minimizes a predetermined evaluation function shown in FIG. 10. In the evaluation function, the performance value (Hw(i), function(j)) for each combination of hardware and function is obtained from the performance data (power consumption, processing time, cost) shown in FIGS. 7, 8, and 9. Then, the chip-middle allocation function 108 allocates the combination of hardware and function found to minimize the evaluation function to each hierarchical level of the system hardware configuration. Here, security level information output from the system virtual model 106 may be used as the performance data.
[0041] 11 and 12 show examples of functions allocated to computational resources capable of parallel processing in a multimodal sensing system of an autonomous or remotely controlled mobile transport robot 410 equipped with a robot arm and computing resources in a factory, as a specific example to which the application function allocation system 1 is applied. FIG. 11 is a flowchart of processing executed by application software of the multimodal sensing system, and FIG. 12 is a diagram showing an example of the hardware configuration of the multimodal sensing system and the functions that are divided and executed.
[0042] The multimodal sensing system of this embodiment is composed of an autonomous or remotely controlled mobile transport robot 410 having a robot arm and computing resources, a sensor unit 420, edge PCs 430 and 440, and an edge server 450.
[0043] First, sensor unit 420 acquires a two-dimensional field of view image of the periphery of mobile transfer robot 410 and the distance to an object within the field of view from a two-dimensional camera or three-dimensional sensor (LiDAR, stereo camera) installed on mobile transfer robot 410 using a software development kit (SDK) or the like from the camera vendor (1101). Sensor unit 420 also communicates with a control device (not shown) that controls mobile transfer robot 410 to acquire status information of mobile transfer robot 410 (1102). Sensor unit 420 also acquires audio of the periphery of mobile transfer robot 410 from a microphone installed on mobile transfer robot 410 using a software development kit (SDK) or standard library from the microphone vendor (1103).
[0044] Thereafter, the edge PC 430 detects one or more objects in the two-dimensional image acquired in step 1101, extracts distance information to the detected objects, and calculates the distance to the detected objects (1104).
[0045] The edge PC 430 also uses the information about the detected object and the distance information acquired in step 1104 to generate position information within the 2D image of the video content for screen display relating to the detected object. The generated content is used for autonomous or remote control of the detected object. In the case of autonomous operation, the content is for notifying workers near the robot on the factory floor of the robot's working status, and in the case of remote control, the content may be necessary for the remote operator to improve operability. The content display method may also be changed depending on the distance (1105).
[0046] The edge PC 430 also superimposes the guideline generated in step 1105 onto the two-dimensional video to synthesize the display data for displaying the content (1106).
[0047] Furthermore, the edge PC 440 executes synchronization processing of the two-dimensional video and the audio data based on the timestamp of the two-dimensional video and the timestamp of the audio data, and integrates the two-dimensional video and the audio data (1107).
[0048] The edge PC 440 also encodes and compresses the integrated data including the 2D video and audio data, and transmits the encoded data to the edge server 450 (1108).
[0049] In the case of autonomous driving, the computing resources provided in the mobile transport robot 410, or in the case of remote control, the edge server 450, decodes the integrated data of the encoded 2D video and audio data (1109), outputs the 2D video to a display device, and outputs the audio from a speaker (1110). Here, it is assumed that a display for displaying and a speaker for audio playback are connected to the mobile transport robot 410 and the edge server 450.
[0050] As described above, according to the embodiment of the present invention, a virtual model representing the characteristics of chips and middleware is constructed, thereby enabling the performance of chips constituting a system in which multiple chips with different functions work together to achieve a single purpose to be used efficiently. For example, as an edge PC, there are options for a two-chip configuration (edge PC 430 and edge PC 440), a single edge PC 430, or a PC with abundant computing resources. However, when power consumption performance is required due to on-site battery-operated conditions (e.g., continuous operation of mobile transport robot 410 for eight hours), a system configuration that meets the required performance can be realized by dividing the processing load between two computing resources (edge PC 430 and edge PC 440).
[0051] 13 and 14 show an example of functions allocated to computational resources that execute processes serially in a vibration diagnosis system for equipment operating in a factory, as a specific application example of the application function allocation system 1. FIG. 13 is a flowchart of the processing executed by application software of the vibration diagnosis system, and FIG. 14 is a diagram showing an example of the hardware configuration of the vibration diagnosis system and the functions that are divided and executed.
[0052] The vibration diagnosis system of this embodiment includes a diagnosis target device (for example, an air compressor) 510, a sensor unit 520, an edge controller 530, and a cloud server 540.
[0053] First, the sensor unit 520 converts the analog output of the vibration sensor installed inside the monitored device into digital data using an AD converter, and acquires the converted digital data using the AD converter library (1201).
[0054] Then, the sensor unit 520 performs envelope processing to calculate an envelope waveform, which is a curve connecting the maximum and minimum values of the vibration signal waveform over a predetermined period, from the digital data of the vibration measured by the vibration sensor (1202). The envelope processing may be a combination of signal squaring and low-pass filtering, or may use a Hilbert transform.
[0055] The edge controller 530 performs 1203 a fast Fourier transform (FFT) process on the envelope waveform calculated in step 1202 .
[0056] Then, the edge controller 530 extracts a characteristic frequency from the frequency peak extracted by the FFT processing in step 1203 and sends it to the cloud server 540 (1204). The extracted characteristic frequency may be set to a frequency range that can be theoretically calculated, such as for motor bearing fault diagnosis, or multiple frequencies may be set as characteristic frequencies in descending order of peak amplitude value. Furthermore, the characteristic frequency may be set to a frequency band in which a steep change is observed by calculating the RMS value using a sliding window for the frequency range for operation data of a new diagnosis target device, a diagnosis target device that has been in use for several years, and a faulty diagnosis target device.
[0057] The cloud server 540 inputs the data into the trained AI / ML model and analyzes the state of the device to be diagnosed (1205).
[0058] The cloud server 540 determines whether there is a sign of a failure in the device to be diagnosed (1206), and if there is a sign of a failure, issues an alert (1207). The alert issued in step 1207 may be presented via a user interface such as a display screen or warning light of the device to be monitored.
[0059] As described above, according to the embodiment of the present invention, a virtual model representing the characteristics of chips and middleware is constructed, thereby enabling efficient use of the performance of chips constituting a system in which multiple chips with different functions work together to achieve a single purpose. For example, since the sensor unit 520 is installed at low cost at the factory where the target equipment is physically located, low-performance computing resources are deployed. Therefore, the amount of data is reduced by performing only the essential function of vibration data acquisition 1201 and low-load envelope processing. Since the edge controller 530 and cloud server 540 can secure relatively abundant computing resources, processing such as spectrum calculation 1203 and machine learning (AI / ML) 1205 can be deployed to optimize the system.
[0060] 15 and 16 show examples of functions allocated to the computational resources of an SoC or SiP in a device key authentication system operating on an SoC or SiP, with Fig. 15 being a flowchart of processing executed by application software of the device key authentication system, and Fig. 16 being a diagram showing an example of the hardware configuration of the device key authentication system and the functions executed in a divided manner. Note that an SoC is a device in which multiple functions are integrated on a single semiconductor chip, and an SiP is a device in which multiple semiconductor chips with different functions are integrated in a single package.
[0061] The device key authentication system of this embodiment is configured by a processor core including a normal area 610 and a secure area 620, a secure storage 630 in which application data is stored, and a secure unit 640 having a tamper-resistant area.
[0062] First, the processor core executes a key pair generation request process in the normal area 610 (1301).
[0063] The secure storage 630 loads the TA into the secure area 620 (1302). The TA is a trusted application that runs in the secure world and executes secure processing.
[0064] The processor core executes TA in the secure area 620, generates a key pair, and stores the generated key pair in the tamper-resistant area of the secure unit 640 (1303).
[0065] The TA running in the secure area 620 obtains the public key from the secure storage 630 (1304).
[0066] Then, the processor core executes the signature request process in the normal area 610 (1305).
[0067] The TA running in the secure domain 620 signs the message with its private key (1306).
[0068] Then, the processor core executes the verification request process in the normal area 610 (1307).
[0069] The TA running in the secure domain 620 performs the verification and shares the results with the normal domain 610 and the secure domain 620 (1308).
[0070] As described above, according to the embodiment of the present invention, a virtual model representing the characteristics of chips and middleware is constructed, so that the performance of chips constituting a system in which multiple chips with different functions work together to achieve a single purpose can be used without waste. In an example of a device key authentication system that operates on an SoC or SiP, middleware function characteristics are stored in the application (system) specification 201, and functions are assigned by setting a security level as evaluation index information 205.
[0071] The present invention is not limited to the above-described embodiments, but includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added, deleted, or replaced with other configurations.
[0072] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by having a processor interpret and execute a program that realizes each function.
[0073] Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.
[0074] In addition, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily represent all the control lines and information lines that are necessary for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]
[0075] 1. Application function allocation system 10 processors 11 Data Collection Department 12 Output section 13 Allocation processing section 14 Analysis Department 20 memory 30 Storage 31 System Performance Model 32 Middleware Virtual Model 33 Chip Virtual Model 40 Input / Output Interface 45 Communication Interface 50 Allocation calculation unit 60 System Virtual Model Department 70 Middleware Virtual Model Database 75 Chip Virtual Model Database 80 User Interface Section 81 Evaluation index input section 82 System configuration input section 83 Calculation result output section 101 Code Analysis Features 102 Function block division function 103 Functional Data Extraction Function 104 Chip data extraction function 105 Environmental data extraction function 106 System Virtual Model 107 Performance Estimation Function 108 Middle allocation function 201 Application Specifications 202 App Source Code 203 Chip configuration diagram 204 Usage environment information 205 Evaluation Index Information 410 Forklift 420 Sensor Unit 430 Edge PC 440 Edge PC 450 Edge Server 520 Sensor Unit 530 Edge Controller 540 Cloud Server 610 Normal Region 620 Secure Area 630 Secure Storage 640 Secure Unit
Claims
1. A distribution system for assigning application programs to hardware and middleware, It is composed of a computer having an arithmetic unit that performs predetermined arithmetic processing and a storage device connected to the arithmetic unit, The aforementioned computing unit includes an input unit that accepts the specification of evaluation metrics for optimizing parameters related to the operation of a target system on which the application runs, The aforementioned computing device includes an allocation processing unit that assigns combinations of chip virtual models and middleware virtual models recorded in a database, and the operating modes of each virtual model, based on the input application specifications and evaluation indicators received by the input unit. The allocation system is characterized in that the calculation unit has an output unit that outputs the allocation result from the allocation processing unit.
2. The allocation system according to claim 1, The aforementioned input unit is characterized by creating display data for displaying the application code workspace and the system design workspace.
3. The allocation system according to claim 2, The aforementioned allocation processing unit, Based on the input application specifications and the information received by the input unit, the application code is analyzed, divided into functional blocks, and functional data is extracted. The input unit extracts system data and chip data based on the system information and chip information it receives. Middleware function data, the system data, the chip data, and the usage environment data are input into a system virtual model composed of the chip virtual model and the middleware virtual model to extract system performance information. An allocation system characterized by assigning an operating mode to a virtual model based on the extracted system performance information.
4. The allocation system according to claim 3, The aforementioned input unit is characterized by accepting chip mounting hierarchy information, the number of computing resources, and computing resource information as input information.
5. The allocation system according to claim 4, The aforementioned allocation processing unit, Based on the chip implementation hierarchy information input to the input unit, the arrangement of computing resources on the hierarchy is determined. An allocation system characterized by virtualizing multiple chips located within the same hierarchical layer as an integrated chip when multiple computing resources are arranged in parallel on the same hierarchical layer.
6. The allocation system according to claim 4, The aforementioned allocation processing unit, Based on the chip implementation hierarchy information input to the input unit, the arrangement of computing resources on the hierarchy is determined. An allocation system characterized by virtualizing multiple chips arranged in series on multiple layers as an integrated chip.
7. An allocation system for allocating application programs to hardware and middleware, It is composed of a computer having an arithmetic unit that performs predetermined arithmetic processing and a storage device connected to the arithmetic unit, The aforementioned computing device includes an input unit that accepts the specification of an indicator for which optimization is to be evaluated, The aforementioned computing device includes an allocation processing unit that assigns combinations of chip virtual models and middleware virtual models recorded in a database, and the operating modes of each virtual model, based on the input application specifications and the indicators received by the input. The allocation system is characterized in that the calculation unit has an output unit that outputs the allocation result from the allocation processing unit.
8. An allocation system for allocating application programs to hardware and middleware, It is composed of a computer having an arithmetic unit that performs predetermined arithmetic processing and a storage device connected to the arithmetic unit, The aforementioned arithmetic unit includes an input unit that accepts the specification of an index, The aforementioned computing device includes an allocation processing unit that assigns combinations of chip virtual models and middleware virtual models recorded in a database, and the operating modes of each virtual model, based on the input application specifications and the indicators received by the input unit. The calculation device has an output unit that outputs the result of the allocation by the allocation processing unit, The input unit creates display data for displaying the application code workspace and the system design workspace. The aforementioned allocation processing unit, Based on the input application specifications and the information received by the input unit, the application code is analyzed, divided into functional blocks, and functional data is extracted. The input unit extracts system data and chip data based on the system information and chip information it receives. Middleware function data, the system data, the chip data, and the usage environment data are input into a system virtual model composed of the chip virtual model and the middleware virtual model to extract system performance information. An allocation system characterized by assigning an operating mode to a virtual model based on the extracted system performance information.