CN110138604B - Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things - Google Patents

Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things Download PDF

Info

Publication number
CN110138604B
CN110138604B CN201910356053.XA CN201910356053A CN110138604B CN 110138604 B CN110138604 B CN 110138604B CN 201910356053 A CN201910356053 A CN 201910356053A CN 110138604 B CN110138604 B CN 110138604B
Authority
CN
China
Prior art keywords
hardware
internet
things
database
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910356053.XA
Other languages
Chinese (zh)
Other versions
CN110138604A (en
Inventor
董玮
高艺
李博睿
程志浩
刘汶鑫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang University ZJU
Original Assignee
Zhejiang University ZJU
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang University ZJU filed Critical Zhejiang University ZJU
Priority to CN201910356053.XA priority Critical patent/CN110138604B/en
Publication of CN110138604A publication Critical patent/CN110138604A/en
Application granted granted Critical
Publication of CN110138604B publication Critical patent/CN110138604B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

A multi-performance-index-oriented automatic generation method for an Internet of things hardware platform comprises the following steps: (1) establishing a hardware performance database, wherein the hardware performance database comprises the following four parts: a hardware energy consumption database, a hardware processing speed database, an API calling speed database, a hardware interface and a price database; (2) analyzing the user requirement file and the user writing program logic; (3) generating dynamic constraint conditions of the hardware platform of the Internet of things, wherein the dynamic constraint conditions comprise two indexes: application execution time and average energy consumption; (4) generating static constraint conditions of the hardware platform of the Internet of things, wherein the static constraint conditions comprise two indexes: hardware platform scalability and price; (5) and (4) solving an optimization problem, inputting the static and dynamic constraint conditions obtained by conversion in the step (3) and the step (4) and an optimization target declared by a user, and solving the optimal hardware configuration of the Internet of things by using a solver of a mixed integer nonlinear programming problem.

Description

Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things
Technical Field
The invention relates to prediction of key performance indexes (such as energy consumption and real-time performance) of an Internet of things hardware platform and a method for automatically generating a hardware module in the Internet of things hardware platform to be connected with the hardware module according to the requirement of a user on the key performance indexes of nodes.
Background
In recent years, with the development of technologies such as micro-electromechanical technology (MEMS), new sensors and microcomputers are in endless, and the application of the internet of things based on these hardware is also rapidly increasing. According to statistics, the number of internet of things devices in 2017 all over the world reaches 84 hundred million, and is increased by 31 percent compared with 64 hundred million in 2016, and the number of internet of things devices exceeds the global population (75 hundred million) for the first time. According to conservative predictions, the number of globally active internet of things devices will reach 215 hundred million in 2025.
However, the development process of the internet of things application is still inefficient compared to the development of the conventional Personal Computer (PC)/clustered server software application. This is because the hardware architectures of the PC and the server have tended to be unified (e.g., the cpu uses von neumann architecture), and the application developer only needs to be concerned with the software development work thereon. However, the internet of things application includes the selection of hardware platform modules and the development of corresponding applications. Generally, an internet of things hardware platform is a specially-customized embedded system including a Micro-Control Unit (MCU), a communication module and other sensors, and internet of things software applications need to be customized according to different hardware platforms. The hardware platform of the internet of things is generally divided into three parts: mainboard, shield board and peripheral hardware. The main board mainly includes main computing components (such as MCU, memory, etc.) of the system, the shield board is an expansion component inserted on the main board, and generally functions to provide more interfaces, and the peripheral is directly connected to the main board or indirectly connected to the main board through the shield board to provide sensing, control, etc. functions. Therefore, so far, no universal internet of things equipment platform is dominant in the market due to the strong coupling of the internet of things hardware and software.
Due to this, it is very difficult for non-professionals in the field of internet of things or embedded systems to create an application of internet of things that meets their needs for two reasons: (1) the hardware platform of the internet of things and the components thereof are various and are mutually heterogeneous, so that the non-professional person in the large model selection space can hardly find the most suitable hardware. (2) Hardware developers have varying requirements for developing hardware platforms and their software. For example, in some scenarios, the low power performance of the application is emphasized, while in other scenarios, the price of the hardware device as a whole may be a priority. This diversity offers a number of possibilities for the internet of things hardware platform construction, but also brings great complexity: namely, various requirements such as complex interfaces, voltages and the like need to be met among hardware components.
Due to the two development difficulties, although the number of the devices of the internet of things is rapidly increased, the application of the internet of things does not penetrate into the daily life of human beings like the application of a PC or a server, and the low development efficiency of the application of the internet of things is a big bottleneck in the development of the internet of things. The selection problem of hardware needs to consider the following points:
(1) adaptability of user performance requirements: key performance indexes such as price, energy consumption and expandability of the generated hardware need to meet the requirements of users.
(2) Adaptability of software: the hardware selected is required to support the functions required by the developer (such as WiFi connection, temperature sensing, driving relay, etc.)
(3) Hardware suitability: such as supply voltage, number and type of physical interfaces
The performance requirements of users can be divided into two categories: dynamic indicators and static indicators. Static indicators refer to attributes that are not relevant to the program logic (e.g., price); dynamic indicators are closely related to program logic (e.g., power consumption).
Disclosure of Invention
The invention aims to overcome the defects in the prior art, and provides a method for automatically generating an optimal hardware platform of the internet of things by automatically analyzing the user requirements and predicting key performance indexes of the hardware platform of the internet of things and solving an optimization problem.
In order to realize the purpose, the technical scheme adopted by the invention is as follows: a multi-performance-index-oriented Internet of things hardware platform automatic generation method comprises the following steps:
(1) establishing a hardware performance database, wherein the hardware performance database comprises the following four parts: a hardware energy consumption database, a hardware processing speed database, an API calling speed database, a hardware interface and a price database.
(2) The analysis of the user requirement file and the user writing program logic comprises the following steps:
and 2.1) analyzing the user requirement file, acquiring the requirement file which is used for declaring each performance index of the Internet of things hardware platform and is expected to be generated by the user, and analyzing to obtain a mathematical expression of the user requirement.
2.2) analyzing the program logic written by the user, and generating a control flow graph of the code and the weight of each control flow branch by using a code static analysis method.
(3) Generating dynamic constraint conditions of the hardware platform of the Internet of things, wherein the dynamic constraint conditions comprise two indexes: the application execution time and the average energy consumption comprise the following specific steps:
3.1) generating dynamic constraint conditions of the application execution time, and generating nonlinear inequalities (or optimization targets) of the constraint conditions according to the application execution time prediction model and user requirements.
And 3.2) generating a dynamic constraint condition by applying the average power consumption, and generating a nonlinear inequality (or an optimization target) of the constraint condition according to the application average power consumption prediction model and the user requirement.
(4) Generating static constraint conditions of the hardware platform of the Internet of things, wherein the static constraint conditions comprise two indexes: the extensibility and the price of the hardware platform comprise the following specific steps:
4.1) generating an extensibility static constraint condition, and generating a constraint condition primary inequality (or an optimization target) according to an extensibility calculation model and user requirements.
And 4.2) generating a static constraint condition of the total applied price, and generating a primary inequality (or an optimization target) of the constraint condition according to the computation model of the total applied price and the user requirement.
(5) And (3) solving an optimization problem, inputting the static and dynamic constraint conditions obtained by conversion in the step 3) and the step 4) and an optimization target declared by a user, and solving the optimal hardware configuration of the Internet of things by using a solver of a mixed integer nonlinear programming problem.
The invention has the advantages that: compared with the prior art, when the Internet of things equipment platform is automatically generated, in addition to consideration of consistency of electrical characteristics among the Internet of things equipment and integrity of a hardware platform for logic support of a user, various important performance indexes (such as power consumption, expandability, execution time and total price) of the Internet of things hardware platform which are difficult for a developer to obtain are modeled and used as constraint conditions or optimization targets generated by the hardware platform, so that the hardware platform which best meets application requirements of the developer on the Internet of things is generated, trial and error cost of the developer is reduced, and development processes of the Internet of things of the developer are greatly accelerated.
Drawings
Fig. 1 is a flow chart of generating an internet of things device platform according to the present invention.
FIG. 2 is an application control flow graph generated by the program flow analysis of the present invention and the resulting hardware configuration.
Detailed Description
According to the method, the optimal Internet of things hardware platform is automatically generated by solving the optimization problem through automatically analyzing the user requirements and predicting the key performance indexes of the Internet of things hardware platform. In order to realize the purpose, the technical scheme adopted by the invention is as follows: a multi-performance-index-oriented Internet of things hardware platform automatic generation method comprises the following steps:
(1) establishing a hardware performance database, wherein the hardware performance database comprises the following parts: the method comprises the following steps of a hardware energy consumption database, a hardware processing speed database, an API calling speed database, a hardware interface and a price database, and specifically comprises the following steps:
(1.1) establishing a hardware energy consumption database, wherein an energy consumption recorder is used for energy consumption, a test program is that an API runs once every 1s, and the API sleeps at other times. And acquiring the API runtime energy consumption by recording the periodic energy consumption data output by the energy consumption recorder. Recording the energy consumption and the corresponding calling duration of the APIf corresponding to the energy consumption level k on the component i and the mainboard j, and respectively recording the energy consumption and the corresponding calling duration as
Figure BDA0002045461640000051
And
Figure BDA0002045461640000052
and (1.2) establishing a speed database by hardware processing. The number y of MCU cycles required for assembly code corresponding to the grammar rule u on the platform i of the programming languagei,uAccording to the data sheet of the platform, with the aid of the formula ti,u＝yi,u/νiηiObtaining the hardware processing speed t corresponding to the grammar rule ui,u。
And (1.3) establishing an API call speed database. Firstly, classifying hardware platforms according to the architecture thereof (such as ARM Cortex, AVR ATMega, TI MSP series and the like), measuring API levels of representative hardware and Application Programming Interfaces (API) in each class, inserting timestamps before and after API execution by using a code instrumentation mode at single API calling time, and obtaining the execution time of the API on the corresponding hardware platform by the difference value of the two timestamps; and on the basis of the basic database, the method is subjected to horizontal and vertical automatic off-line expansion so as to automatically complete the complete measurement of the hardware platform and the API.
(1.3.1) the horizontal extension refers to that modeling is carried out according to quantitative performance indexes (such as core clock frequency, instruction set throughput rate and the like) among different individual platforms in the same type, and a database of all the individual platforms in the type is generated through extension. The calling time of the API is related to the core clock frequency of the hardware platform and the throughput rate of the instruction set, and the corresponding formula is ti,f＝ti′,fvi′ηi′/viηi. Wherein t isi,f/ti′,f、vi/vi′And ηi/ηi′The invocation time of the APIf of platforms i and i', the platform core clock frequency and the instruction set throughput rate, respectively.
(1.3.2) the longitudinal expansion refers to that calculation is carried out according to the ratio of the measurement result of the basic API and the quantized resource occupation indexes (such as code counting, system function calling times and the like) between the APIs, and the database of all the APIs is generated by expansion on the same hardware platform.
(1.4) establishing a hardware interface and price database, wherein the database contains information of the quantity and the type of the hardware interface and the market price of the hardware, and the information can be obtained from a manufacturer data manual.
(2) Analysis of user demand files and user written program logic.
And (2.1) analyzing the user requirement file, acquiring the requirement file which is used for declaring each performance index of the Internet of things hardware platform and is expected to be generated by the user, wherein the requirement file comprises an optimization target expected by the user and constraint conditions of each performance index, and analyzing to obtain a mathematical expression of the user requirement. If the user demand is 'minimize energy consumption and the whole price is lower than 100 RMB', the generation is carried outThe mathematical expression is
Figure BDA0002045461640000061
Wherein
Figure BDA0002045461640000066
And
Figure BDA0002045461640000067
respectively representing the energy consumption and price of the generated hardware platform
(2.2) analyzing program logic written by a user, obtaining a program control flow graph by using a code static analysis method based on Valgrind, and performing taint analysis (taint analysis) on key variables in branch points and loop points to reversely trace the program logic to locate variable sources. Due to the application particularity of the internet of things, if the variable value is related to the external environment (if a certain condition is that the external humidity is greater than 90%, the environment prediction of a user is introduced as input, and finally a control flow graph of a code and the weight of each control flow branch are generated.
(3) Generating dynamic constraint conditions of the hardware platform of the Internet of things, wherein the dynamic constraint conditions comprise two indexes: the application execution time and the average energy consumption comprise the following specific steps:
(3.1) applying the generation of the execution time dynamic constraint condition, wherein the generation comprises the following two parts:
and (3.1.1) establishing a code execution time dynamic index prediction model. This patent uses vector d to represent a particular internet of things hardware platform
Figure BDA0002045461640000062
Figure BDA0002045461640000063
And
Figure BDA0002045461640000065
representing the totality of main boards, shields and peripherals in the database, a binary selection variable diRepresenting whether hardware i is selected, which may take the value 1 or 0, e.g. diTable 1 (the attached drawings)Hardware i is shown contained in the final generated hardware platform. The variable d in step 4) and step 5) is as defined herein.
For a specific Internet of things hardware platform d and user application program U, the code running time of the Internet of things equipment
Figure BDA0002045461640000064
May be expressed as a time t to call an Application Programming Interface (API)API(d) Runtime t of non-API codel(d) And sleep time tidleThe sum of (U) is as follows:
Figure BDA0002045461640000071
specifically, it can be further expressed as:
Figure BDA0002045461640000072
wherein a binary selection variable diAnd djRepresenting hardware or whether selected, which may take on values of 1 or 0, e.g. d i1 means that hardware i is included in the finally generated hardware platform; f and l represent the set of full API and full non-API code obtained from the user code,
Figure BDA0002045461640000073
and
Figure BDA0002045461640000074
representing all shields and peripherals in the database that provide the APIf,
Figure BDA0002045461640000075
representing the totality in the database, βfAnd βuRepresents the running counts of APIf and non-API code u weighted by the path; t is ti,j,fIs the running time, t, of APIf on motherboard i and peripheral ji,uThe running time of non-API codes on the mainboard i; phi (U) is sleep time extracted from user code UOperating;
and (3.1.2) generating constraint conditions. Based on the runtime database of steps 1.2) and 1.3), and the user code path information obtained in step 2.2), the runtime calculation formula of the user code can be obtained by using the formula (1) and the formula (2) in step 3.1.1), and a quadratic inequality, that is, the constraint condition (or optimization target) of the code execution time, can be obtained by combining the user constraint information (or optimization target) in step 2.1).
(3.2) generating an average power consumption dynamic constraint condition, wherein the generation comprises two parts of the establishment of a prediction model and the generation of the constraint condition:
and (3.2.1) establishing a prediction model by applying the average power consumption dynamic index. The average power consumption of an internet of things hardware platform can be expressed as the average power consumption of each component in one code cycle. Because different mainboards have different electrical characteristics, even if the same peripheral and shield board are plugged into different mainboards, the different mainboards can have different power consumption values. Therefore, for a specific Internet of things hardware platform d and a user application program U, the average power consumption of the running code of the Internet of things equipment
Figure BDA0002045461640000081
Can be expressed as:
Figure BDA0002045461640000082
wherein a binary selection variable diAnd djRepresenting hardware or whether selected, which may take on values of 1 or 0, e.g. d i1 denotes that hardware i is included in the finally generated hardware platform, Pi(U) and Pi,j(U) represents the average power consumption of hardware i or hardware i, j when running code U, and may be specifically expressed as:
Figure BDA0002045461640000083
Figure BDA0002045461640000084
is the energy of component iGrade of consumption, use
Figure BDA0002045461640000085
And
Figure BDA0002045461640000086
sets representing idle energy consumption and active energy consumption levels, respectively, then
Figure BDA0002045461640000087
Figure BDA0002045461640000088
(or
Figure BDA0002045461640000089
) And
Figure BDA00020454616400000810
(or
Figure BDA00020454616400000811
) Is the duty cycle and power consumption value of component i (or component i on motherboard j) at power consumption level k; the duty cycle being the ratio of the active time to the total time, i.e.
Figure BDA00020454616400000812
And
Figure BDA00020454616400000813
wherein
Figure BDA00020454616400000814
Is the time that component i is at power consumption level k,
Figure BDA00020454616400000815
is a collection of APIs provided by the component i,
Figure BDA00020454616400000816
is the length of time that calling APIf of component i at motherboard j will cause i to enter the kth power consumption level, βfRepresenting the running count of the api weighted by the path,
Figure BDA00020454616400000817
representing the time required to run one cycle of code, is obtained from step 3.1).
And (3.2.2) generating constraint conditions. Based on the hardware energy consumption database in the step 1.1) and the user code path information obtained in the step 2.2), an average energy consumption calculation formula of the user code can be obtained by using the formula (3) and the formula (4) in the step 3.2.1), and a quadratic inequality, namely a constraint condition (or an optimization target) of average energy consumption can be obtained by combining the user constraint information (or the optimization target) in the step 2.1).
(4) Generating static constraint conditions of the hardware platform of the Internet of things, wherein the static constraint conditions comprise two indexes: the extensibility and the price of the hardware platform comprise the following specific steps:
and (4.1) generating expandability index constraint conditions of the hardware platform of the Internet of things. In this patent, the scalability of the hardware platform of the internet of things is defined as the number of physical interfaces still remaining on the motherboard after the hardware connection required by the user application is completed. It can use the number of the physical interfaces remained after the connection is completed by calculation
Figure BDA0002045461640000091
And the number of MCU pins remaining
Figure BDA0002045461640000092
Collectively representing a particular internet of things hardware platform d
Figure BDA0002045461640000093
And
Figure BDA0002045461640000094
can be expressed as:
Figure BDA0002045461640000095
Figure BDA0002045461640000096
wherein a binary selection variable diRepresenting hardware or whether selected, which may take on values of 1 or 0, e.g. d i1 means that hardware i is included in the finally generated hardware platform;
Figure BDA0002045461640000097
and
Figure BDA0002045461640000098
representing all main boards, shield boards and peripheral equipment in the database;
Figure BDA0002045461640000099
and
Figure BDA00020454616400000910
representing a set of physical interface types and interface communication types, respectively, i.e.
Figure BDA00020454616400000911
Figure BDA00020454616400000912
Each Port occupies two of the pins,
Figure BDA00020454616400000913
while
Figure BDA00020454616400000914
And
Figure BDA00020454616400000915
is a triplet<i,W,I>The number of physical interfaces that are provided/consumed,
Figure BDA00020454616400000916
and
Figure BDA00020454616400000917
is a triplet<i,W,I>MCU pin number provided/consumed.
The user's requirements for a certain type of extensibility can be based on formula (5) and formula (b)6) And step 1.4), expressing the hardware interface quantity database by using a mathematical expression, and combining the user requirements of step 2.1) to further convert the hardware interface quantity database into an inequality about hardware platform selection. Since the number of the remaining pins is determined by the number of the remaining physical interfaces and the number of the MCU pins, the user's requirement for a certain interface will be converted into a physical interface number constraint and an MCU pin constraint. If the user's demand is "more than 6 pins of the remaining I2C type", this will be translated into
Figure BDA00020454616400000918
And (4.2) generating price constraint conditions of the hardware platform of the Internet of things. Such as a specific internet of things hardware platform diThe price of (c) can be expressed as:
Figure BDA0002045461640000101
wherein
Figure BDA0002045461640000102
Represents the price, c, of a particular Internet of things hardware platform diIs the price of component i, a binary selection variable diRepresenting hardware or whether selected, which may take on values of 1 or 0, e.g. d i1 means that hardware i is included in the finally generated hardware platform,
Figure BDA0002045461640000103
and
Figure BDA0002045461640000104
representing the totality of the motherboard, shield and peripherals in the database.
The constraint condition (or optimization target) of the user on the price can be expressed by using a mathematical expression according to the formula (7) and the hardware price database in the step 1.4), and a piece of information about d can be generated by combining the user requirement in the step 21)iThe inequality of (b) is a mathematical expression of the price constraint.
(5) And (3) solving an optimization problem, inputting the static and dynamic constraint conditions obtained by conversion in the step 3) and the step 4) and an optimization target declared by a user, wherein the dynamic constraint conditions are non-linear mixed integer inequalities about d, so that a non-linear mixed integer programming problem solver is required to be used by the solver. And solving the optimal hardware configuration d of the Internet of things by a solver.
The embodiments described in this specification are merely illustrative of implementations of the inventive concept and the scope of the present invention should not be considered limited to the specific forms set forth in the embodiments but rather by the equivalents thereof as may occur to those skilled in the art upon consideration of the present inventive concept.

Claims (1)

1. A multi-performance-index-oriented Internet of things hardware platform automatic generation method comprises the following steps:
(1) establishing a hardware performance database, wherein the hardware performance database comprises the following four parts: a hardware energy consumption database, a hardware processing speed database, an API calling speed database, a hardware interface and a price database;
(2) the analysis of the user requirement file and the user writing program logic comprises the following steps:
2.1) analyzing the user requirement file, acquiring a requirement file which is used for declaring each performance index of the Internet of things hardware platform expected to be generated by the user, and analyzing to obtain a mathematical expression of the user requirement;
2.2) analyzing the program logic written by a user, and generating a control flow graph of the code and the weight of each control flow branch by using a code static analysis method;
(3) generating dynamic constraint conditions of the hardware platform of the Internet of things, wherein the dynamic constraint conditions comprise two indexes: the application execution time and the average energy consumption comprise the following specific steps:
3.1) generating dynamic constraint conditions of the application execution time, and generating nonlinear inequalities or optimization targets of the constraint conditions according to an application execution time prediction model and user requirements, wherein the application execution time prediction model is shown as a formula (1);
Figure FDA0002421881840000011
equation (1) represents a particular internet of things hardware platform using a vector d, d ═ d1,d2,...,di}，
Figure FDA0002421881840000012
Figure FDA0002421881840000013
And
Figure FDA0002421881840000014
representing the totality of main boards, shields and peripherals in the database, a binary selection variable diRepresenting whether the hardware i is selected, wherein the value of the hardware i is 1 or 0; u represents a user application program code operated by the equipment of the Internet of things;
Figure FDA0002421881840000015
for the internet of things device running code time for a particular internet of things hardware platform d and user Application U, it can be expressed as time t of calling Application Programming Interface (API)API(d) Runtime of non-API code
Figure FDA0002421881840000016
And sleep time tidleThe sum of (U) may be further specifically represented as:
Figure FDA0002421881840000021
wherein a binary selection variable diAnd djRepresenting whether hardware i or j is selected, wherein the value of the hardware i or j is 1 or 0; f and
Figure FDA00024218818400000221
representing the collection of the totality of APIs and the totality of non-API code obtained from the user code,
Figure FDA0002421881840000022
and
Figure FDA0002421881840000023
representing all shields and peripherals in the database that provide the APIf,
Figure FDA0002421881840000024
representing the totality of the boards in the database, βfAnd βuRepresents the running counts of APIf and non-API code u weighted by the path; t is ti,j,fIs the running time, t, of APIf on motherboard i and peripheral ji,uThe running time of non-API codes on the mainboard i; Φ (U) is an operation of extracting sleep time from the user code;
3.2) generating dynamic constraint conditions by applying average power consumption, generating nonlinear inequalities or optimization targets of the constraint conditions according to an applied average power consumption prediction model and user requirements, wherein the applied average power consumption prediction model is shown as a formula (3);
Figure FDA0002421881840000025
wherein a binary selection variable diAnd djRepresenting whether hardware is selected, its value is 1 or 0, Pi(U) and Pi,j(U) represents the average power consumption of hardware i or hardware i, j when running code U, and may be specifically expressed as:
Figure FDA0002421881840000026
Figure FDA0002421881840000027
is the energy consumption class, usage, of component i
Figure FDA0002421881840000028
And
Figure FDA0002421881840000029
sets representing idle energy consumption and active energy consumption levels, respectively, then
Figure FDA00024218818400000210
Figure FDA00024218818400000211
And
Figure FDA00024218818400000212
is the duty cycle and energy consumption value of component i at energy consumption level k;
Figure FDA00024218818400000213
and
Figure FDA00024218818400000214
is the duty cycle and energy consumption value of component i at energy consumption level k on motherboard j; the duty cycle being the ratio of the active time to the total time, i.e.
Figure FDA00024218818400000215
And
Figure FDA00024218818400000216
Figure FDA00024218818400000217
wherein
Figure FDA00024218818400000218
Is the time that component i is at power consumption level k,
Figure FDA00024218818400000219
is a collection of APIs provided by the component i,
Figure FDA00024218818400000220
it is at motherboard j that invoking APif of component i will cause i to go to kth energyTime length of consumption level, βfRepresenting the running count of the api weighted by the path,
Figure FDA0002421881840000031
representing the time required to run one cycle of code, obtained from step 3.1);
(4) generating static constraint conditions of the hardware platform of the Internet of things, wherein the static constraint conditions comprise two indexes: the extensibility and the price of the hardware platform comprise the following specific steps:
4.1) generating an extensible static constraint condition, and generating a constraint condition primary inequality or an optimization target according to an extensible calculation model and user requirements, wherein the extensible calculation model is shown as a formula (5);
the extensibility of a particular IOT hardware platform d can be expressed as the remaining amount of hardware interfaces
Figure FDA0002421881840000032
And the residual amount of MCU pins
Figure FDA0002421881840000033
They can be represented as:
Figure FDA0002421881840000034
Figure FDA0002421881840000035
wherein a binary selection variable diWhether the hardware is selected or not is represented, and the value of the hardware is 1 or 0;
Figure FDA0002421881840000036
and
Figure FDA0002421881840000037
representing all main boards, shield boards and peripheral equipment in the database;
Figure FDA0002421881840000038
and
Figure FDA0002421881840000039
representing a set of physical interface types and interface communication types, respectively, i.e.
Figure FDA00024218818400000310
Each Port occupies two of the pins,
Figure FDA00024218818400000311
while
Figure FDA00024218818400000312
And
Figure FDA00024218818400000313
is a triplet
Figure FDA00024218818400000318
The number of physical interfaces that are provided/consumed,
Figure FDA00024218818400000314
and
Figure FDA00024218818400000315
is a triplet
Figure FDA00024218818400000316
The number of MCU pins provided/consumed;
4.2) generating a static constraint condition of the total price, generating a first-order inequality or an optimization target of the constraint condition according to a calculation model of the total price and the user requirement, wherein the calculation model of the total price is applied as shown in a formula (7);
Figure FDA00024218818400000317
wherein
Figure FDA0002421881840000041
Representing the price of a specific internet of things hardware platform d; c. CiIs the price of component i; binary selection variable diRepresenting whether hardware is selected, which takes the value of 1 or 0,
Figure FDA0002421881840000042
and
Figure FDA0002421881840000043
representing all main boards, shield boards and peripheral equipment in the database;
(5) and (3) solving an optimization problem, inputting the static and dynamic constraint conditions obtained by conversion in the step 3) and the step 4) and an optimization target declared by a user, and solving the optimal hardware configuration of the Internet of things by using a solver of a mixed integer nonlinear programming problem.
CN201910356053.XA 2019-04-29 2019-04-29 Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things Active CN110138604B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910356053.XA CN110138604B (en) 2019-04-29 2019-04-29 Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910356053.XA CN110138604B (en) 2019-04-29 2019-04-29 Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things

Publications (2)

Publication Number Publication Date
CN110138604A CN110138604A (en) 2019-08-16
CN110138604B true CN110138604B (en) 2020-06-09

Family

ID=67575591

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910356053.XA Active CN110138604B (en) 2019-04-29 2019-04-29 Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things

Country Status (1)

Country Link
CN (1) CN110138604B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113821920A (en) * 2021-09-06 2021-12-21 重庆大学 Application scene-oriented Internet of things terminal hardware customization platform and method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663539A (en) * 2012-03-20 2012-09-12 昆明悟然科技有限公司 Operation cost management system based on platform of internet of things
CN106027319A (en) * 2016-07-22 2016-10-12 中国科学院计算技术研究所 Simulation IOT resource service system and method
US9917903B2 (en) * 2015-12-28 2018-03-13 Verizon Patent And Licensing Inc. Internet of things provisioning
CN107992339A (en) * 2017-11-15 2018-05-04 浙江大学 A kind of method for automatically generating Internet of things node hardware configuration

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102271379B (en) * 2011-05-09 2013-09-18 陈实 Energy-saving routing method of nodes of internet of things based on context-aware technology
CN103973717B (en) * 2013-01-24 2017-11-21 中国科学院计算技术研究所 A kind of internet-of-things terminal remolded
CN105045096A (en) * 2015-08-26 2015-11-11 福建恒天晨光节能服务有限公司 Intelligent energy saving method based on neural network and system thereof

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663539A (en) * 2012-03-20 2012-09-12 昆明悟然科技有限公司 Operation cost management system based on platform of internet of things
US9917903B2 (en) * 2015-12-28 2018-03-13 Verizon Patent And Licensing Inc. Internet of things provisioning
CN106027319A (en) * 2016-07-22 2016-10-12 中国科学院计算技术研究所 Simulation IOT resource service system and method
CN107992339A (en) * 2017-11-15 2018-05-04 浙江大学 A kind of method for automatically generating Internet of things node hardware configuration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
towards rapid and cost-effective prototyping of IoT platforms;董玮;《IEEE》;20161111;全文 *

Also Published As

Publication number Publication date
CN110138604A (en) 2019-08-16

Similar Documents

Publication Publication Date Title
Becker et al. Model-based performance prediction with the palladio component model
Noureddine et al. Monitoring energy hotspots in software: Energy profiling of software code
Becker et al. The Palladio component model for model-driven performance prediction
Sahin et al. Initial explorations on design pattern energy usage
Raghavan et al. Model based estimation and verification of mobile device performance
Mooney Issues in the specification and measurement of software portability
US7340717B2 (en) Method for providing enhanced dynamic system simulation capability outside the original modeling environment
CN110138604B (en) Multi-performance-index-oriented automatic generation method for hardware platform of Internet of things
Deng et al. Cost-driven autonomous mobility
Janka Specification and design methodology for real-time embedded systems
Noureddine Towards a better understanding of the energy consumption of software systems
Chowdhury et al. Emulating I/O behavior in scientific workflows on high performance computing systems
Le et al. An approach to modeling and estimating power consumption of mobile applications
Miller et al. Evaluating a basic approach to sensor network node programming
Chakravarthi et al. System on Chip (SOC) Architecture: A Practical Approach
Yassin et al. Fast and accurate edge computing energy modeling and DVFS implementation in GEM5 using system call emulation mode
Koskela et al. Principles for automated and reproducible benchmarking
Gandini et al. A framework for automated detection of power-related software errors in industrial verification processes
CN106020982A (en) Method for simulating resource consumption of software component
Kerbyson et al. Is predictive tracing too late for HPC users?
Dai et al. Toward efficient execution of mainstream deep learning frameworks on mobile devices: Architectural implications
CN113689173B (en) Modeling device and modeling method of business logic representation model
Manotas Gutiérrez Developing a software engineer's energy-optimization decision support framework
Hammond et al. Predictive simulation of HPC applications
Taie et al. Methods for prediction, simulation and verification of real-time software architectural design based on machine learning algorithms

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant