Method and device for providing timing independence of software and computer readable medium

Abstract

The invention provides a method and device for providing timing independence of software and a computer readable medium. The present disclosure provides timing independence to software. Changes such as nondeterminacy, randomization, and similar items are appended to software. A distribution of unspecific modalities established with association with the software is discriminated. The non-specific modalities include modalities within the critical path, modalities outside design timing constraints of the software, modalities at the end of the timing range, and similar modalities. At least a portion of the software is modified to remove non-specific modalities by implementing the modifications to prevent overdesign of implemented hardware and overfitting of the software to implemented hardware; optimizing execution of tasks of the software; reconfiguring the execution sequence of the non-dependent tasks not in the critical path; and similar operations and the like.

Description

Technical Field

[0001] The present description relates to a process for providing timing independence to software and methods of using the process. Background Art

[0002] Historically, software has been executed in conditions that minimize sources of variation from an execution time perspective. By minimizing sources of variation, it is easier to achieve overall system reliability. For example, it is common to constrain execution time (e.g., a braking system needs to apply the brakes within a certain number of milliseconds). In addition, the variation in execution time means that multiple systems are intertwined in complex ways, making it difficult to fully predict the execution of observable combinations, create a larger state space to analyze for accuracy, and verify more possible failure paths. However, this approach means that software changes are difficult to make (which can be the last straw that breaks the camel's back), and (since timing is largely dictated by the specific hardware) the software is tied to the hardware.

[0003] Vehicles are beginning to use more non-real-time hardware and operating systems to meet some of the benchmarks. Therefore, the traditional approach to timing hinders software reuse and deployment and is becoming increasingly unrealistic.

[0004] As well as meeting the quality objectives for software, it is also preferred to decouple software from hardware. Therefore, it is still useful to understand the timing impact of changes in the software level. This requirement needs to be balanced with other criteria such as portability, reuse, hardware independence, modifiability of software, etc. Summary of the invention

[0005] In at least one embodiment, a method of providing timing independence to software includes: adding a change to the software; identifying a distribution of non-specific modalities associated with the software; and modifying at least a portion of the software to remove the non-specific modality.

[0006] In at least one embodiment, the device includes: a memory storing computer-readable instructions; and a processor connected to the memory, the processor being configured to execute the computer-readable instructions to perform the following processing: appending changes to the software; identifying the distribution of non-specific modalities associated with the software; and modifying at least a portion of the software to remove the non-specific modality.

[0007] In at least one embodiment, a non-transitory computer-readable medium stores computer-readable instructions that, when executed by a processor, cause the processor to: append changes to the software; identify the distribution of non-specific modalities associated with the software; and modify at least a portion of the software to remove the non-specific modality. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The scheme of the present disclosure will be best understood by using the accompanying drawings and reading the following detailed description. It should be noted that, in accordance with industry practice, various features are not depicted to scale. In fact, the size of various features may be increased or decreased to make the description clear.

[0009] Figure 1 Indicates a system with both priority and common applications installed.

[0010] Figure 2 Indicates the timing of performing an action in at least one embodiment.

[0011] Figure 3 It represents a plurality of tasks accomplished by an execution unit in at least one embodiment.

[0012] Figure 4 Represents two modes of at least one embodiment.

[0013] Figure 5 Memory alignment randomization is represented in accordance with at least one embodiment.

[0014] Figure 6 Represents a critical path of events with dependencies for at least one implementation.

[0015] Figure 7 Represents three modes of at least one embodiment.

[0016] Figure 8a The effects of changing the timing of calling and responding to an API in at least one embodiment are shown.

[0017] Figure 8b The effects of changing the timing of calling and responding to an API in at least one embodiment are shown.

[0018] Fig. 9 is a flow chart of a method of providing timing independence to software in accordance with at least one embodiment.

[0019] Fig.10 is a high-level functional block diagram of a processor-based system of at least one embodiment. DETAILED DESCRIPTION

[0020] The embodiments described in this specification record examples of various features for realizing the subject matter provided. In order to simplify the present disclosure, examples related to constituent elements, values, actions, materials, configurations or similar items are described below. Of course, these are examples and are not intended to be limiting. Assume that other constituent elements, values, actions, materials, configurations or similar items. For example, in the following description, forming a first feature above or on a second feature includes an embodiment in which the first feature is directly in contact with the second feature, including an embodiment in which an additional feature is formed between the first feature and the second feature in a manner in which the first feature and the second feature cannot be in direct contact. In addition, the present disclosure repeats reference numbers and / or reference texts in various examples. The repetition is for the purpose of simplification and clarification, and does not specify the relationship between the various embodiments and / or structures described.

[0021] Furthermore, spatially relative terms such as "below", "below", "below", "above", "above" and similar terms are used in this specification to facilitate description of the relationship of a certain element or feature relative to another element or feature as shown in the figures. In addition to the orientation depicted in the figures, spatially relative terms are intended to include various orientations of the device when in use or in operation. The device is in a different orientation (rotated 90 degrees or other orientations), and the spatially relative descriptions used in this specification are also interpreted accordingly.

[0022] In at least one embodiment, a method of providing timing independence to software includes: adding a change to the software; identifying a distribution of non-specific modalities associated with the software; and modifying at least a portion of the software to remove the non-specific modality.

[0023] The embodiments described in this specification provide methods that provide more than one advantage, for example, methods and situations are listed that can still meet the goal of meeting the timing dependency and enable the software to have a certain degree of timing independence.

[0024] In most cases, the system executes multimodal software. The software is executed multiple times and a plot is taken of the frequency of events versus time. For example, the design of the intended software provides 100 milliseconds to perform some action. The action is repeated every 100 milliseconds. Thus, the software effectively performs the same action continuously.

[0025] One problem with software is fragility, where any small change to the software can cause the critical path to overrun and impact timing. Critical and non-critical paths can be automatically identified through various tools such as Place & Route. By identifying these paths, scheduling can be automatically performed around the critical path, or at least the timing requirements of the non-critical path software can be relaxed (until the non-critical path becomes critical). This approach relaxes the rules around timing criticality, where only the actual timing critical software is considered, automating the support goals.

[0026] Another issue is combinatorial complexity, which can prevent timing from being varied and tried and tested to a workable implementation that is always explicit. However, the latest superscalar hardware is essentially executed by speculation made by the latest operating systems, which means that having separate timings often does not work. Therefore, accept that timings will change, and test the possibility thoroughly. One way to deal with this is to simply intentionally add more changes to the timing, even when testing or when executing in production.

[0027] Figure 1 A system 100 is shown with priority applications and common applications installed.

[0028] exist Figure 1 In the embodiment, different partitions 110, 120 are configured to separate various application domains, that is, to merge mixed-criticality applications, and to utilize hardware resources as efficiently as possible. A real-time operating system (RTOS) 112 can be used to call a priority application 114. General-purpose applications 124 can be performed using an operating system 122, such as an RTOS or a more general operating system such as a Windows (registered trademark) operating system or a Linux (registered trademark) operating system. A separate processor or a multi-core processor 130 can be used to execute applications 114, 124. Therefore, each partition 110, 120 has its OS and an application domain, such as an identification, configured on the OS. Various timing constraints and mapping constraints for tasks, OS schedulers (i.e., assigning tasks and schedulers to specific cores) are defined, visualized, confirmed, and verified.

[0029] The application layer is typically a complex software layer that performs set functions or responds to a set of inputs. Applications 114, 124 are typically called through operating systems 112, 122 such as RTOS, which are themselves designed to guarantee latency and provide deterministic actions. RTOS112 and priority applications 114 are typically interfaced to a hardware driver library built for priority design standards. The driver layer guarantees latency and determinism through the structure of an application programming interface (API) that limits the functions called by the application. The design of the API using priority constraints sets the foundation for higher-level software and functions as a system design constraint set to guarantee priority actions.

[0030] Figure 2 The timing of performing act 200 according to at least one embodiment is shown.

[0031] exist Figure 2 In at least one embodiment, events 210 are plotted relative to time 220. When an action is performed, events 230 are taken. At first glance, the events appear to be distributed at random times. However, in response to sampling by the software, events 230 are roughly clustered around a given time. Figure 2 , events 230 are distributed within a specified time boundary 240 of, for example, 1 millisecond (ms). Figure 2 The time boundaries 240 for events 230 in are clustered in a 1 ms window 240 starting from 5 ms 242 and ending at 6 ms 244. However, events, such as event 250 at 10 ms, may occur outside of the clusters.

[0032] When taking action, the processor uses context switches between time boundaries of, for example, 1 millisecond. An event starts, the operating system causes a context switch to perform some processing, and then the process returns to the execution of the action. Therefore, the context switch may take a relatively large amount of time, for example, the total time may take 10 milliseconds. In the priority system, an attempt is made to remove delays and outliers, such as event 250 at 10ms. For example, priority software can be involved in autonomous vehicles, robots, medical devices, or similar projects, and problems arise due to the inability to predict whether an event is scheduled to take 1 millisecond or scheduled to take 10 milliseconds. For priority software, this unpredictable delay may cause serious damage or injury to property or people, an example of which is a car switching from autonomous mode to manual mode without the driver being prepared, a robot functioning in a way that kills or injures someone, etc.

[0033] Priority systems are designed to prevent reliability issues caused by latency. In contrast, this often occurs with a mobile phone or laptop computer. For example, in response to a user scrolling in a browser, the scrolling process sometimes hangs for a period of time before continuing. The user can observe this phenomenon, but continues to scroll. However, with priority applications, this type of glitch cannot occur to avoid the damage or injury mentioned above.

[0034] In most cases, software is designed to perform actions as quickly as possible. However, for priority software, the goal is reliability, for example, a task should always be completed within a given time frame 240, such as 1 millisecond, to prevent adverse effects on safety or action. Moreover, in practice there are a variety of tasks that are executed continuously and simultaneously.

[0035] Figure 3 The plurality of tasks performed by the execution unit 310 according to at least one embodiment are shown.

[0036] exist Figure 3 In the example, the execution unit schedules tasks or actions. In most cases, the completion of a task is called an event. The execution unit 310, such as a CPU or multiple cores in a multi-core processor, continuously schedules tasks 320. Dependencies 322 and 324 sometimes exist between tasks. In most cases, a task 326 generates data used by the next task 328. Thus, an order of dependencies is generated, where the time boundary related to the execution of the task is a specified amount of time 330, for example, the task should be executed within 100 milliseconds (ms). The 1 millisecond boundary 340 of the task can include a start error boundary 342 and an end error boundary 344 that define the period during which the task can start and end. The complete execution of all tasks should be completed within the 100 millisecond time boundary 330.

[0037] Therefore, in most cases, a buffer or margin is built into the execution of the tasks, and there are time boundaries not only in the entire 100 milliseconds 330, but also in the individual tasks 320, and there are dependencies 322, 324 between the tasks. For example, the first task 326 should be executed before the second task 328 can start. Therefore, the execution unit 310, for example in a real-time operating system (RTOS), schedules the tasks 320 so that the tasks are executed within the 100 millisecond time frame 330. A variation of 1 millisecond 340 is represented between the start time and the end time. The start time and the end time include the modal time amount, for example 1ms340. As Figure 2 The illustrated time boundary 240 of 1 millisecond occurs, for example, between 5 milliseconds 242 and 6 milliseconds 244 .

[0038] Figure 4Two modes 400 are shown of at least one embodiment.

[0039] exist Figure 4 , the first group of events 410 are gathered in the time boundary 1 (mode 1 412) of 1 ms from 5 ms 414 to 6 ms 416. The second group of events 420 are gathered in the time boundary 2 (mode 2 422) of 1 ms from 10 ms 424 to 11 ms 426. However, those skilled in the art will understand that other modes can be generated. Therefore, in the real world, there should not always be a single mode, and in most cases there will be multiple modes. Therefore, mode 1 412 is generated within 1 millisecond from 5 milliseconds 414 to 6 milliseconds 416, and mode 2 422 is generated in milliseconds from 10 milliseconds 424 to 11 milliseconds 426. However, there is uncertainty as to which mode is generated. The two modes 412, 422 can be generated when the software is executed continuously, or not necessarily in the executing software, but when the function is appended to somewhere in the software. Various modalities can be generated in response to the software being compiled once and sent to the vehicle, where only one mode is modified. However, in response to other portions of the software being compiled and re-executed, Mode 2 422 can be identified.

[0040] Therefore, as described below, to identify timing problems, variants or non-determinism are added to the software, or the generation of unknown modes is forced. The forcing of modes increases the likelihood of identifying problems during development testing, thereby increasing safety even if the statistical probability of the mode occurring in production or after the software is deployed is low. Dynamic application of randomness caused by intentionally inserted non-determinism is used to attempt to disrupt the software to identify the problem.

[0041] Figure 5 Memory alignment randomization 500 is shown in accordance with at least one embodiment.

[0042] exist Figure 5 In the memory layout of software is randomized so that the order of execution of the software changes from one execution to another, thereby causing modality. However, memory allocation in software is accompanied by the prior allocation of many memories or scratch buffers that are allocated linearly.

[0043] Figure 5Represents a memory 510 that is allocated four inputs, e.g., input 1 512, input 2 514, input 3 516, input 4 518, in response to a particular action. In response to the fifth input being accessed, the software crashes. The following process is performed sequentially by the software: allocate input 1 512, then allocate input 2 514, then allocate input 3 516, then allocate input 4 518. Thus, the allocation can be fully predicted. In this case, any kind of cache effect or how the caches function or how the caches interact with each other is presented in a predictable manner.

[0044] Intentional non-determinism can be added to a part of the software that changes the timing in hardware. An example is randomization of address space configuration, which has a tendency to expose modalities in software timing because caches in hardware (data cache, TLB (Translation Lookaside Buffer), branch prediction, etc.) tend to change in the presence of "false sharing" or "true sharing", which in turn depends on how ASLR (Address Space Layout Randomization) chooses to align (virtual or physical) addresses. True sharing of data occurs when two cores attempt to access and modify the same word, resulting in consecutive invalidations of the cache line in the other core. "False sharing of data" occurs when two cores attempt to access and modify two different words in the same cache line, resulting in consecutive invalidations of the cache line in the other core.

[0045] Therefore, according to at least one embodiment, for both testing and production, the order in which memories 520 are allocated is randomized, with the result that instead of allocating input 1 512, input 2 514, input 3 516, and input 4 518 in sequence as shown in memory 510, a random number generator or pseudo-random number generator 530 is used to provide variation to the order, with allocation being performed sequentially to enforce compliance with the modality. For example, through randomization, memories 520 are allocated in the order of input 3 522, input 1 524, input 4 526, and then input 2 528.

[0046] For example, when the executable file is placed inside the memory, various modes are caused by changes in page alignment. Therefore, even if no code is changed, when the code is placed inside the memory, the mode changes. The reason for the mode change is that the way the cache functions in the hardware changes. The mode changes are not only due to recompilation, but also sometimes due to execution on different hardware.

[0047] Therefore, the use of ASLR and more use of ASLR exposes modal behavior by enforcing false / true sharing. ASLR can be generalized to other places that can be randomized or made non-deterministic to force areas that expose modal behavior. Another example is the case of assigning hash algorithms or constants to associative containers.

[0048] The software can also be executed on two Advanced RISC Machine (ARM) CPUs (Central Processing Units), where the ARM CPUs are different versions. The same time boundaries can be used, but the software is executed in various modes on different hardware.

[0049] With regard to vehicles, manufacturers strive to have a single mode, but having multiple modes can cause manufacturers to go over budget. For example, manufacturers build two modes and calculate worst-case behavior for both modes. However, timing is overrated, which leads to an over-budget. Software building blocks have multiple worst-case scenarios stacked together, which leads to further over-estimation.

[0050] In order to be able to update the software over time, the knowledge of the generated patterns and the execution method of the software is used. In order to use the software in various versions of hardware, the knowledge of various patterns is useful, but the time to generate multiple patterns may vary.

[0051] Typically, for priority software such as autonomous driving software, robots, medical devices, nuclear power plants, aircraft, and similar projects, the software is developed and then tested specifically for its intended purpose and the conditions it will experience. The current industry best practice for security is to write the software and then prevent any changes to the critical software.

[0052] In contrast, according to at least one embodiment, for example, as with reference to Figure 5As described in the randomization of memory allocation described, changes are built into the entire development process. Mode switching can occur at any time and anywhere. Any small change may be the last straw that breaks the camel's back, where the software does not meet the timing constraints, for example, the execution timing does not fit within the boundary of 100 milliseconds. The goal of at least one embodiment is to improve the quality of software, reduce costs, and enable software to be delivered at a higher speed, which in part includes reusing software over time and updating software over time. In order to update software over time, the software solution cannot be immutable to prevent the software from being changed. By accepting that changes will be made, it is also necessary to accept the existence of multimodal software. Therefore, the multimodal problem should be solved as early as possible. If it is not solved as early as possible, any change to the software is a big stumbling block, because the change will cause timing changes or cause untested unpredictable effects. Therefore, multimodality should be exercised early in the development process.

[0053] Therefore, as software is developed, variation is forced, so the software is built in a flexible way, so unknown bands are forced, so that modifications are developed to deal with previously unknown problems. In most cases, this change will result in a morphism that comes from small changes. Variation is forced within the software, so the software encounters situations that the software would not normally encounter.

[0054] The construction of changes into the software is the same as the concept called TAKT (Takt Time), which includes aligning the manufacturing process with customer demand. TAKT time is an indicator that represents the calculation of the available production time divided by the customer demand. For example, in a factory that works 480 minutes a day and customers request 240 products a day, the TAKT time is two minutes. Similarly, in a case where customers want two new products per month, the TAKT time is two weeks. The purpose is to accurately align production with demand. There is also a concept called ChaosMonkey, which is a tool that helps applications tolerate random instances of poor resilience. Production plots are drawn regularly to identify what is happening to prevent interruptions to the production process. Changes or poor performance are introduced into the production environment to resist failures. According to at least one embodiment, variants are built into the software development process as a timed testing process for the software. Make an event that occurs 0.0001% of the time occur 1% of the time, so that the event cannot be avoided.

[0055] Figure 6 A critical path 600 of events with dependencies is shown for at least one embodiment.

[0056] exist Figure 6In the example, dependent tasks / events 610, event 612, dependent tasks / events 620, event 622, and dependent tasks / events 630, event 632, event 634 can be identified, and the execution of tasks can be reconfigured. The execution order of tasks / events can be dynamically swapped in each execution. By swapping the execution order, non-critical effects are exposed.

[0057] The critical path can be identified, the critical path is prioritized, and the order of execution of other tasks can be shifted and changed. The reordering of tasks can be changed statically just once or can be changed dynamically. The critical path is the most important path, that is, the longest path required to complete.

[0058] exist Figure 6 In the example, first, event 1 640 is generated. Then, event 2 610, event 4 620, and event 3 630 are scheduled after event 1 640. Event 5 612, which depends on event 2 610, is scheduled after event 2 610, and event 6 622, which depends on event 4 620, is scheduled after event 4 620. Event 7 632, which depends on event 3 630, is scheduled after event 3 630, and event 8 634, which depends on event 7 632, is scheduled after event 7 632. Event 9 650 is scheduled after event 8 634. Furthermore, event 9 650 is scheduled after event 5 612 and event 6 622. Then, event 10 660 is completed after event 9 650. There are various places where changes can be added. Not all tasks have dependencies on each other. For convenience, non-dependent tasks are generated in a way that they are scheduled serially. Eventually, a task supplies its output to other dependent tasks.

[0059] exist Figure 6 In , the critical path is path 670. Figure 6 As shown, the critical path 670 includes event 1 640, event 3 630, event 7 632, event 8 634, event 9 650, and event 10 660. The critical path 670 is the path with the longest execution time, so the tasks within the critical path 670 cannot be reordered. However, the order of other tasks can be reconfigured. For example, event 5 612 can be scheduled with event 7 632 or event 8 634. Similarly, event 2 610 can be scheduled with event 3 630 or event 7 632. Similarly, event 6 622 can be scheduled with event 7 632 or event 8 634, and event 4 620 can be scheduled with event 3 630 or event 7 632. The reordering of the execution of these tasks affects the change of the critical path.

[0060] While tasks are executed linearly, other tasks loop around the critical path 670 or alter execution in other CPUs. For systems with multiple execution units, the order of execution can change. This can force cache effects or expose the modality of execution.

[0061] The forcing of modalities increases the likelihood of identifying problems during development testing, thus increasing safety even if the modalities have a low statistical probability of occurring in production or after the software is deployed. The application of randomness to reorder events is accomplished by intentionally inserting non-determinism in an attempt to dynamically and continuously disrupt the software to identify problems. As described, problems occur at 0.0001%, and by adding non-determinism, problems occur at a frequency greater than 0.0001%, such as 0.01%, with the result that problems can be addressed before production and before the software is deployed.

[0062] Another approach is to make software reuse efficient, for example, by enabling software to evolve over time. For example, the current version of the software has no problems. However, changes are built into the execution of the software, with the result that when software changes are made, possible patterns can be searched for. In order to consider and manage future changes and optimize the allocation of hardware, non-deterministic randomness is introduced into testing and production.

[0063] The introduction of non-determinism provides tolerance for more than what is actually specified, i.e., the software is not over-provisioned. When software is changed or an upgrade is implemented, the software is tested by introducing non-determinism to ensure that no problems arise. The introduction of non-determinism not only prevents over-design of hardware, but also prevents over-fitting current software to current hardware.

[0064] For example, when a new vehicle is manufactured, the hardware is changed and the software is reused. The software is created for the new hardware. In the case where the new software is kept constant, such as when changes are not allowed, when the new software is used in the new hardware, the new hardware is overfit to the software. Instead, the introduction of non-determinism provides a broader view of the mode, and safety is ensured by careful planning and deployment of a complete understanding of the hardware and software.

[0065] Figure 7 Three modes 700 are shown representing at least one embodiment.

[0066] exist Figure 7, the timing constraint is 100 milliseconds 710. A first set of events 720 are clustered in time boundary 1 (pattern 1 724) of 1 ms 722. A second set of events 730 are clustered in time boundary 2 (pattern 2 734) of 1 ms 732. A third set of events 740 are clustered in time boundary 3 (pattern 3 744) of 1 ms 742.

[0067] Subassembly 0 750, subassembly 1 751, subassembly 2 752, subassembly 3 753, subassembly 4 754, subassembly 5 755, subassembly 6 756, and subassembly 7 757 are shown below the plot. Instead of measuring the timing of each of subassembly 0 750 to 7 757, the timing of all executions of subassembly 0 750 to 7 757 is measured. The order of execution is changed, and the mode distribution is taken in.

[0068] When events are randomized, multiple modes are exposed and superimposed. The mode on the right, mode 3 744, is very rare in normal execution, but randomization exposes mode 3 744. Software developers can try to avoid mode 3 744, so the software developer examines the software to determine why mode 3 744 occurs, such as which subcomponents 0 750-7 757 are part of the critical path. The distribution plot representing the three modes 700 allows the software developer to know where time should be spent to optimize execution, to reduce variation, etc., so mode 3 744 can be shifted to the left so that the variation is not too close to the time constraint 710 of 100 milliseconds to ensure safety.

[0069] According to at least one embodiment, software and hardware are separated. Thus, the hardware can be floating point, or the software can be floating point, or both can be floating point. Depending on the nature of the system, one does not interrupt the other. Thus, software is not moved into production in response to software interruption, or software is rolled back very quickly because testing can identify the significant edge case. By removing non-specific modes, such as modes outside of the design timing constraints or modes that are too close to the design timing constraints, such as Mode 3 744, the planning and mitigation issues related to true safety can be addressed even as the system becomes more and more complex.

[0070] The quality of the software is ensured by the identification of edge cases, such as Mode 3 744, in terms of compatibility of the software with the associated hardware. Complexity in the static model is considered, as well as complexity in the dynamic model of changes associated with both software and hardware. This can be applied not only to the deployment of a specific model line, but also to changes within that model line in completely different models. Insight into all details of software and hardware is not required to mitigate risk.

[0071] Randomization can be introduced into the software in several ways. Figure 6 Dependencies such as those described are introduced based on the order in which events are scheduled. As mentioned above, current software development methods prevent arbitrary changes.

[0072] The allocation order can also be Figure 5 Other randomization techniques include oversize allocations (allocations that exceed requests), code allocations, use of various commands, and the like.

[0073] For example, software commands are generated in a way that performs a collection of tasks. In most cases, the commands are equivalent or at least generate the same results. Therefore, a variety of commands can be used, for example, for x86 systems, there are identical commands such as addition, load effective address (LEA) and so on. LEA is executed on different execution units, introducing a certain amount of variation in the execution, because LEA uses different resources. In addition, a variety of commands that are equivalent for a given purpose can be selected that generate different results. For example, for floating point math, a version that uses 16-bit floating point commands (called F16) and 32-bit floating point commands (called F32) can be used.

[0074] Figure 8a-8b The effects of changes in the timing of API calls and responses 800 are shown in at least one embodiment.

[0075] exist Figure 8a In FIG, events about requests 1 to 3 810, 820, 830 and events about responses 1 to 3 812, 822, 832 are shown. In software testing, virtual hardware can simulate timing-critical defects in the system by listing all timing APIs that can produce race conditions. An event represents an execution instance of a statement or sequence of statements in a program. An event specifies a collection of shared memory locations that are read and / or written. Events do not necessarily occur instantaneously, and in parallel programs, events are sometimes unordered. The timing of an event is specified by the instants of its start and end. In the case where the start of e1 occurs after the start of e2 and before the end of e2, or vice versa, events e1 and e2 are simultaneous. The tracing function helps to isolate system problems by monitoring selected system events.

[0076] exist Figure 8a814, the request 1810 generated between t0812 and t1814 represents a request for deceleration associated with a vehicle, such as a rail vehicle, a car, and the like. However, those skilled in the art will appreciate that other implementations that match the embodiments disclosed in this specification can be applied. The response 1812 generated between t1814 and t2822 represents a deceleration applied to the vehicle.

[0077] Request 2 820 generated between t2 822 and t3 824 represents a recognized request related to deceleration for a track switch of a vehicle (in this specific example, the vehicle is a railway vehicle). Response 2 822 generated between t3 824 and t4 832 represents the recognized location of the track switch.

[0078] The request 3830 generated between t4832 and t5834 indicates a request for a track switch of the vehicle at the identified track switch position. The response 3832 generated between t5834 and t6836 indicates a track switch of the vehicle implemented at the identified track switch position.

[0079] In different executions of the same program with the same input, the access events that constitute a race may sometimes occur in different orders, which may sometimes lead to different program behavior (non-determinism). For example, multiple threads may sometimes access the same variable in shared memory at the same time, and at least one of the accesses may modify the variable, which may sometimes lead to errors.

[0080] An application programming interface (API) is a set of defined rules that enable different applications to communicate with each other. For example, the memory management API is used to allocate memory, the data management API is used to access data, and the socket API provides a form of inter-process communication (IPC) and is used to send messages in the network. There are many other types of APIs.

[0081] APIs designed for real-time rendering use a pipelined execution model. A race condition refers to a bug that occurs due to the timing or order of execution of multiple actions. A bug is an error, defect, or undesirable condition in the design, development, or operation of computer software that causes the software to fail or produce unexpected results or act in an unexpected manner. Race conditions are a very broad class of bugs that can manifest themselves in very different ways depending on the problem space. For example, multiple threads creating multiple API calls using the same resources can sometimes produce different results due to different API timing.

[0082] exist Figure 8b In the introduction of bad conditions related to the interweaving of actions of the API with regard to considerations, defects are introduced into the software in order to identify timing issues. Formal methods can be used to identify the portion of the software that depends on timing, and then, to enumerate all potential execution paths. This leads to the subsequent identification of all potential bad modes and the creation of a test plan that needs to test all of these bad modes (automatically or manually).

[0083] Figure 8b Again, the command to decelerate the vehicle is shown, showing that request 1 850 is generated between t0 852 and t1 854. Response 1 852 generated between t1 854 and t2 862 shows the initiation of deceleration of the vehicle.

[0084] Variations are added in such a way that request 2 860 , response 2 862 , request 3 870 , and response 3 872 are shifted in time, thereby generating race conditions between request 2 860 and request 3 870 , and between response 2 862 and response 3 872 .

[0085] Here, the request 2 860 is generated between t1854 and t2862, indicating a request for identification related to the deceleration of the track switch of the vehicle. Here, the response 2 862 is generated between t2862 and t3864, indicating the identified track switch position.

[0086] Here, request 3870 is generated between t1854 and t2862, indicating a request for track switching of the vehicle at the identified track switching position. Here, response 3872 is generated between t2862 and t3864, indicating the track switching of the vehicle implemented at the identified track switching position. However, request 3870 for track switching at the identified track switching position and request 2860 for identification related to deceleration of track switching of the vehicle are simultaneous. Similarly, response 3872 for track switching at the identified track switching position and response 2862 for identifying the track switching position are simultaneous. Therefore, since response 2862 is not completed and the identification of the track switching position is not known before the track switching action is performed, the track switching cannot be performed according to request 3870 and response 3872.

[0087] By appending this source of non-determinism, modal behavior is quantified and ranges are determined for the timing of various implementations. This quantification enables discovery of different software / hardware parts and ensures that all are within the operational design region of the system. A complete listing of timing issues (e.g., a fully formalized approach) also provides a "timing application range" for the system, identifying how many timing modalities are implemented and quantified. Estimates of worst-case bounds representing unimplemented modalities (modalities not covered) can be identified.

[0088] Software can also be modified in production to identify if the real world software has experienced timing that does not conform to the developed model to date. Any overruns can be reported and an investigation can be initiated to understand why the model is wrong. Moreover, not only can the focus be on unexpected overruns, but also on the distribution curve of expected runtime execution behavior. The investigation can be restarted in response to the model of the expected statistics that the runtime does not conform to the expected. Testing can be performed virtually at varying fidelity relative to the hardware. The fidelity level of the simulation / emulation is linked to the establishment of the model, and the fidelity of the less accurate model can be quantified using more accurate virtual tests. Therefore, the variability of timing can be managed and multi-modal behavior is exposed. When software and hardware evolve, new modes are sometimes generated. Through the above methods, situations that generate new modes can be identified, and the changes in the range of considered behaviors and new bad paths considered can be quantified. Hypothetical hardware that represents other behaviors and exposes other modes can be created. Identification of non-specific modes and bad paths makes creation of new hardware easier because the risk of timing becoming an issue in the new platform is reduced because the scale of the timing changes is known in advance.

[0089] To further improve the above situation, some types of algorithms respond more efficiently to synchronization in specific timing events. For example, direct networking to RAM responds more efficiently when the timing is fully quantified. Similarly, the operating system scheduler can reduce timing variability in response to the scheduler being adjusted, which requires quantification of potential variability as described above. This optimization is non-interference, which is the same as the known reduction in interference associated with security systems. In addition, some algorithms such as RCU (Read Copy Update) respond to having custom quiescence points to reclaim memory as quickly as possible (especially in real-time operating systems) and function more fully. By allowing the system to quantify timing variations, it is possible to find methods that meet other benchmarks related to the entire system and optimally schedule and insert quiescence points.

[0090] Fig. 9Flowchart 900 is a method of providing timing independence to software in accordance with at least one embodiment.

[0091] exist Fig. 9 In the method, the method starts at S902 and at S910, the changes are added to the software. Figure 4 In order to identify timing problems, variation or nondeterminism is added to the software, or unknown patterns are forced to occur. The forcing of patterns increases the likelihood of identifying the problem during development testing, thereby increasing safety even if the pattern has a low statistical probability of occurring in production or after the software is deployed. The dynamic application of randomness caused by intentionally inserting nondeterminism is used to attempt to disrupt the software to identify the problem. Figure 5 , the memory layout of the software is randomized so that the order of execution of the software changes from one execution to another, thus appearing modal. Figure 7 Other randomization techniques include over-capacity allocation (allocation in excess of requests), code allocation, use of a variety of commands, and the like.

[0092] In S914, the distribution of non-specific modalities associated with the software is identified. Figure 7 , by removing non-specific modes, such as those outside the design timing constraints, it is possible to address real safety-related planning and mitigation issues even as the system becomes more and more complex. Figure 8a to Figure 8b By appending this source of non-determinism, the modal behavior is quantified and the range of timings for various implementations is determined. This quantification enables the discovery of different software / hardware parts and ensures that all of them are within the operational design region of the system. Figure 6 , the critical path can be identified, the critical path is prioritized, and the execution order of other tasks is shifted and changed. The reordering of tasks can be changed statically only once or can be changed dynamically.

[0093] In S918, at least a portion of the software is modified to remove non-specific modes. Figure 6 , the introduction of non-determinism provides tolerance for exceeding what is actually specified, i.e., the software is not over-provisioned. When software is changed or upgrades are implemented, the software is tested by introducing non-determinism to ensure that no problems arise. The introduction of non-determinism not only prevents over-design of hardware, but also prevents overfitting current software to current hardware. Figure 7 , the distribution plot lets the software developer know where time should be spent to optimize execution, to reduce variation, etc., so pattern 3 744 can be shifted to the left so that the variation does not get too close to the 100 millisecond time constraint 710 to ensure safety.

[0094] Then, the process ends in S920.

[0095] At least one embodiment of a method of providing timing independence to software includes: adding a change to the software; identifying a distribution of non-specific modalities associated with the software; and modifying at least a portion of the software to remove the non-specific modality.

[0096] Fig.10 is a high-level functional block diagram of a processor-based system 1000 of at least one embodiment.

[0097] In at least one embodiment, the processing circuit 1000 provides timing independence to the software. The processing circuit 1000 uses the processor 1002 to implement the addition of timing independence to the software. The processing circuit 1000 also includes a non-transitory computer-readable storage medium 1004 for implementing timing independence in the software. In particular, the non-transitory computer-readable storage medium 1004 is encoded with commands 1006, i.e., computer program code, i.e., stores the commands 1006, i.e., computer program code, wherein the commands 1006 are executed by the processor 1002 to cause the processor 1002 to perform the actions of providing timing independence to the software. The execution of the commands 1006 by the processor 1002 (at least in part) represents an application program to implement at least a portion of the methods described in this specification (hereinafter described processes and / or methods) according to one or more embodiments.

[0098] The processor 1002 is electrically connected to a non-transitory computer-readable storage medium 1004 via a bus 1008. The processor 1002 is electrically connected to an input / output (I / O) interface 1010 via the bus 1008. A network interface 1012 is also electrically connected to the processor 1002 via the bus 1008. The network interface 1012 is connected to a network 1014, and as a result, the processor 1002 and the non-transitory computer-readable storage medium 1004 are connected to external elements via the network 1014. The processor 1002 is configured to execute instructions 1006 encoded in the non-transitory computer-readable storage medium 1004 so that the processing circuit 1000 can be used to perform at least a portion of a process and / or method. In one or more embodiments, the processor 1002 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application specific integrated circuit (ASIC) and / or a suitable processing unit.

[0099] Processing circuit 1000 includes I / O interface 1010. I / O interface 1010 is connected to external circuits. In one or more embodiments, I / O interface 1010 includes a keyboard, keypad, mouse, trackball, touchpad, touch screen, and / or cursor direction keys for transmitting information and instructions to processor 1002.

[0100] The processing circuit 1000 further includes a network interface 1012 connected to the processor 1002. Through the network interface 1012, the processing circuit 1000 can communicate with a network 1014 connected to one or more other computer systems. The network interface 1012 includes a wireless network interface, such as Bluetooth, Wi-Fi (Wireless Fidelity), Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA), or a wired network interface, such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers (IEEE) 864.

[0101] The processing circuit 1000 is configured to receive information through the I / O interface 1010. The information received through the I / O interface 1010 includes one or more of commands, data, design rules, cell libraries, and / or other parameters processed by the processor 1002. The information is transmitted to the processor 1002 via the bus 1008. The processing circuit 1000 is configured to receive information associated with a user interface (UI) through the I / O interface 1010. The information is stored in the non-transitory computer-readable storage medium 1004 as UI 1020.

[0102] In one or more embodiments, instructions 1006 are stored (in compressed or uncompressed form) in one or more non-transitory computer-readable storage media 1004, which can be used to program a computer, processor (or other electronic device) to perform the processes or methods described in this specification. The one or more non-transitory computer-readable storage media 1004 include one or more electronic storage media, magnetic storage media, optical storage media, quantum storage media, or similar storage media.

[0103] For example, the non-transitory computer-readable storage medium 1004 may include a hard disk drive, a floppy disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a magnetic card or an optical card, a solid-state memory device, or other types of physical media suitable for storing electronic commands, but is not limited thereto. In one or more embodiments using optical disks, the one or more non-transitory computer-readable storage media 1004 include a compact disc read-only memory (CD (Compact Disc)-ROM), a compact disc read / write (CD-R / W) and / or a digital video disc (DVD: Digital Video Disc).

[0104] In one or more embodiments, the non-transitory computer-readable storage medium 1004 stores instructions 1006 configured to cause the processor 1002 to perform at least a portion of a process and / or method for providing timing independence to software. In one or more embodiments, the non-transitory computer-readable storage medium 1004 also stores information such as an algorithm that facilitates performing at least a portion of a process and / or method for providing timing independence to software.

[0105] Thus, in at least one embodiment, the processor 1002 executes commands 1006 stored in one or more non-transitory computer-readable storage media 1004 to load, execute, and operate the software 1030 of the test object. The processor 1002 adds changes 1032 to the software, including non-determinism and randomization (e.g., randomization of memory allocation, allocation of excess capacity of memory, or various equivalent commands). The processor 1002 executes commands 1006 stored in one or more non-transitory computer-readable storage media 1004 to determine a distribution 1034 of non-specific modes, such as a distribution associated with modes that are outside the design timing constraints 1036 of the software. The processor 1002 determines a timing range 1038 associated with the execution of tasks, determines events within a critical path and non-dependent tasks 1040 that are not within the critical path. The processor 1002 can reorder non-dependent tasks 1040 that are not within the critical path. The processor 1002 implements modifications to the software 1042 to prevent over-design of the implemented hardware and over-fitting of the software to the implemented hardware. The processor 1002 optimizes the execution of the tasks of the software 1044. The display 1070 provides a user interface (UI) 1072 that presents the software, the distribution of modalities, changes appended to the software, timing ranges, and events / tasks / paths 1074.

[0106] Individual instances of these programs may be executed on any number of individual computer systems, or may be distributed therebetween. Thus, specific steps are described as being performed by specific devices, software programs, processes, or entities, but need not be so. Those skilled in the art will appreciate a variety of alternative implementations.

[0107] Moreover, those skilled in the art will readily appreciate that the above techniques can be utilized in a variety of devices, environments, and situations. The embodiments describe the features of the structure or the behavior of the method using inherent terms, but the subject matter defined in the attached claims is not necessarily limited to the specific features or behaviors described. Instead, the specific features and behaviors are disclosed as exemplary forms of implementing the claims.

Claims

1. A method for providing timing independence to software, comprising: The method comprises: Append changes to the software; Identifying distributions of non-specific modalities associated with said software; and At least a portion of the software is modified to remove the non-specific modality.

2. The method of providing timing independence to software according to claim 1, wherein: The identifying of the distribution of the non-specific modalities associated with the software includes identifying the distribution of modalities that are outside of design timing constraints of the software.

3. The method for providing timing independence to software according to claim 1 or 2, wherein: The addition of the changes to the software includes at least one of the following: adding non-determinism to the software so as to change the timing of execution of tasks performed by the software; or Add randomization to the software, The randomized addition to the software includes at least one of the following: randomized addition of memory allocation, allocation of excess capacity of memory, or replacement of commands of the software with various equivalent commands.

4. The method for providing timing independence to software according to any one of claims 1 to 3, wherein: The identifying of the distribution of the non-specific mode includes: quantifying the non-specific mode; determining a timing range associated with execution of a task of the software; and identifying the non-specific mode at an end of the timing range.

5. The method for providing timing independence to software according to any one of claims 1 to 4, wherein: The identifying of the distribution of the non-specific modality includes: identifying events within a critical path; and reconfiguring an order of execution of non-dependent tasks that are not within the critical path.

6. The method for providing timing independence to software according to any one of claims 1 to 5, wherein: The modification of the at least a portion of the software to remove the non-specific modality includes modifying the at least a portion of the software to prevent over-design of implemented hardware and over-fitting of the software to the implemented hardware.

7. The method for providing timing independence to software according to any one of claims 1 to 6, wherein: The modification of the at least a portion of the software to remove the non-specific modality comprises optimizing the performance of a task of the software.

8. A device for providing timing independence to software, comprising: a memory storing computer-readable commands; and a processor connected to the memory, The processor is configured to execute the computer-readable instructions to: Append changes to the software; Identifying distributions of non-specific modalities associated with said software; and At least a portion of the software is modified to remove the non-specific modality.

9. The apparatus for providing timing independence for software according to claim 8, wherein: The processor is further configured to identify the distribution of the non-specific modalities associated with the software by identifying the distribution of modalities that are outside of a design timing constraint of the software.

10. The apparatus for providing timing independence for software according to claim 8 or 9, wherein: The processor is further configured to append the changes to the software by doing at least one of the following: adding non-determinism to the software so as to change the timing of execution of tasks performed by the software; or Add randomization to the software, The randomized addition to the software includes at least one of the following: randomized addition of memory allocation, allocation of excess capacity of memory, or replacement of commands of the software with various equivalent commands.

11. The apparatus for providing timing independence to software according to any one of claims 8 to 10, wherein: The processor is also configured to identify the distribution of the non-specific modalities by: quantifying the non-specific modalities; determining a timing range associated with execution of a task of the software; and identifying the non-specific modalities at the ends of the timing range.

12. The apparatus for providing timing independence to software according to any one of claims 8 to 11, wherein: The processor is further configured to identify the distribution of the non-specific modality by: identifying events within a critical path; and reconfiguring an order of execution of non-dependent tasks that are not within the critical path.

13. The apparatus for providing timing independence to software according to any one of claims 8 to 12, wherein: The processor is further configured to modify the at least a portion of the software to remove the non-specific modality by modifying the at least a portion of the software to prevent over-design of the implemented hardware and over-fitting of the software to the implemented hardware.

14. The apparatus for providing timing independence to software according to any one of claims 8 to 13, wherein: The processor is further configured to modify the at least a portion of the software to remove the non-specific modality by optimizing execution of tasks of the software.

15. A non-transitory computer-readable medium storing computer-readable instructions, which, when executed by a processor, cause the processor to perform an action, the action comprising: Append changes to the software; Identifying distributions of non-specific modalities associated with said software; as well as At least a portion of the software is modified to remove the non-specific modality.

16. The non-transitory computer readable medium of claim 15, wherein: The identifying of the distribution of the non-specific modalities associated with the software includes identifying the distribution of modalities that are outside of design timing constraints of the software.

17. The non-transitory computer readable medium of claim 15 or 16, wherein: The addition of the changes to the software includes at least one of the following: adding non-determinism to the software so as to change the timing of execution of tasks performed by the software; or Add randomization to the software, The randomized addition to the software includes at least one of the following: randomized addition of memory allocation, allocation of excess capacity of memory, or replacement of commands of the software with various equivalent commands.

18. The non-transitory computer readable medium according to any one of claims 15 to 17, wherein: The identification of the distribution of the non-specific modality comprises at least one of: quantifying the non-specific mode; determining a timing range associated with execution of a task of the software; and identifying the non-specific mode at an end of the timing range; or Identify events within the critical path; and reconfiguring the order of execution of non-dependent tasks that are not within the critical path.

19. The non-transitory computer readable medium according to any one of claims 15 to 18, wherein: The modification of the at least a portion of the software to remove the non-specific modality includes modifying the at least a portion of the software to prevent over-design of implemented hardware and over-fitting of the software to the implemented hardware.

20. The non-transitory computer readable medium according to any one of claims 15 to 19, wherein: The modification of the at least a portion of the software to remove the non-specific modality comprises optimizing the performance of a task of the software.

Images