Providing timing-independence for software

Abstract

To provide a method.SOLUTION: Timing-independence is provided for a software. Variations such as non-determinism, randomization, and the like are added to the software. A distribution of unspecified modalities associated with the software is identified. The unspecified modalities include modalities in a critical path, modalities outside of design timing constraints of the software, modalities at the edge of a timing envelope, and the like. At least a part of the software is modified to eliminate the unspecified modalities by, for example, implementing modifications to prevent over-designing of an implemented hardware and overfitting of the software into the implemented hardware, optimizing execution of tasks of the software, rearranging an order of execution of non-dependent tasks not in the critical path, and the like.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] This specification relates to providing timing independence to software and methods for using same. [Background technology]

[0002] Software has historically been run in a context that minimizes sources of variation in terms of execution time. By minimizing sources of variation, it becomes easier to obtain reliability of the entire system. For example, bounding execution time is a common requirement (e.g., a braking system must apply the brakes within a certain number of milliseconds). Variation in execution time also means that multiple systems may interleave their interactions in complex ways, making it difficult to fully predict the execution of observable combinations, creating a larger state space to analyze for correctness, and forcing more possible failure paths to be examined. However, this approach means that the software is difficult to change (which can backfire) and that the software is tied to the hardware (since timing is largely dictated by the specific hardware).

[0003] Vehicles are beginning to use more non-real-time hardware and operating systems to meet certain standards, and therefore traditional approaches to timing are becoming less practical as they hinder software reuse and deployment.

[0004] As well as satisfying software quality objectives, it is still preferable to have software decoupled from hardware. Therefore, it is still useful to understand the timing implications of software level changes. This requirement must be balanced against other criteria such as portability, reuse, hardware independence, and software modifiability. Summary of the Invention

[0005] In at least an embodiment, a method for providing timing independence to software includes adding variation to the software, identifying a distribution of unspecified modalities associated with the software, and modifying at least a portion of the software to remove the unspecified modalities.

[0006] In at least one embodiment, the apparatus includes a memory storing computer readable instructions and a processor coupled to the memory, the processor configured to execute the computer readable instructions to add variation to the software, identify a distribution of unspecified modalities associated with the software, and modify at least a portion of the software to remove the unspecified modalities.

[0007] In at least one embodiment, the non-transitory computer readable medium has computer readable instructions stored thereon that, when executed by a processor, cause the processor to perform operations of adding variance to the software, identifying a distribution of unspecified modalities associated with the software, and modifying at least a portion of the software to remove the unspecified modalities. [Brief description of the drawings]

[0008] Aspects of the present disclosure are best understood by reading the following detailed description in conjunction with the accompanying figures, in which: It should be noted that, according to industry practice, various features have not been drawn to scale, and in fact the dimensions of various features may be increased or decreased for clarity of illustration.

[0009] [Figure 1] FIG. 1 shows a system in which a safety-critical application and a general-purpose application are implemented. [Diagram 2] FIG. 2 illustrates timing for performing operations in accordance with at least one embodiment. [Diagram 3] FIG. 3 illustrates a number of tasks that may be completed by an executive unit according to at least one embodiment. [Figure 4]FIG. 4 illustrates two modalities according to at least one embodiment. [Diagram 5] FIG. 5 illustrates memory alignment randomization according to at least one embodiment. [Figure 6] FIG. 6 illustrates a critical path of events with dependencies in accordance with at least one embodiment. [Figure 7] FIG. 7 illustrates three modalities according to at least one embodiment. [Figure 8a] FIG. 8a illustrates the effect of introducing timing variations into API calls and responses in accordance with at least one embodiment. [Figure 8b] FIG. 8b illustrates the effect of introducing timing variations into API calls and responses in accordance with at least one embodiment. [Figure 9] FIG. 9 is a flow diagram of a method for providing timing independence to software in accordance with at least one embodiment. [Figure 10] FIG. 10 is a high-level functional block diagram of a processor-based system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] The embodiments described herein describe examples of implementing various features of the provided subject matter. To simplify the disclosure, examples of components, values, operations, materials, arrangements, or the like are described below. Of course, these are examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like are contemplated. For example, forming a first feature above or on a second feature in the following description includes embodiments in which the first and second features are formed in direct contact, and includes embodiments in which an additional feature is formed between the first and second features such that the first and second features are not in direct contact. In addition, the disclosure repeats reference numbers and / or letters in various examples. This repetition is for the purposes of brevity and clarity, and does not dictate a relationship between the various embodiments and / or configurations described.

[0011] Additionally, spatially relative terms such as "lower," "below," "belower," "upper," "above," and the like are used herein for ease of description to describe the relationship of one element or feature to another element or feature as illustrated in the figures. The spatially relative terms are intended to encompass various orientations of the device in use or operation in addition to the orientation depicted in the figures. The device may be oriented differently (rotated 90 degrees or at other orientations) and the spatially relative descriptions used herein interpreted accordingly.

[0012] In at least one embodiment, a method for providing timing independence to software includes adding variation to the software, identifying a distribution of unspecified modalities associated with the software, and modifying at least a portion of the software to remove the unspecified modalities.

[0013] The embodiments described herein provide methods that provide one or more advantages, for example, situations are enumerated along with methods in which software can be made timing independent to some degree while still meeting the goal of satisfying timing dependencies.

[0014] Systems often run multi-modal software. The software is run multiple times and plots of time vs. frequency of events are captured. For example, 100 milliseconds are provided in the design of the software that is intended to perform some action. The action is repeated every 100 milliseconds. Thus, the software is effectively performing the same action continuously.

[0015] One problem with software is fragility, where any small change in the software impacts timing by putting it in a state beyond the critical path. Critical and non-critical paths can be automatically identified through various tools, such as Place&Route. By identifying these paths, one can automatically schedule around the critical path, or at least relax the timing requirements of the non-critical path software (until the non-critical path becomes critical). This aspect relaxes the rules around timing criticality, where only the actual timing critical software is considered, and automation supports the goal.

[0016] Another problem is the combinatorial complexity, which prevents changes in timing for trials that always only expose one possible execution. However, modern superscalar hardware essentially runs through guesses made by modern operating systems, which means that having a single timing is usually useless. Therefore, it is accepted that timings will vary, and this possibility is thoroughly tested. One way to do this is to simply intentionally add more variation in the timings during testing, or even during production runs.

[0017] FIG. 1 shows a system 100 that implements priority and general purpose applications.

[0018] In Fig. 1, the different partitions 110, 120 are arranged to separate the various application domains, i.e. to merge mixed criticality applications, and to utilize the hardware resources as efficiently as possible. A real-time operating system (RTOS) 112 is available to call the priority applications 114. The general-purpose applications 124 can be executed using an operating system 122, e.g. an RTOS or a more general operating system such as a Windows operating system or a Linux operating system. A separate processor or a multi-core processor 130 is available to execute the applications 114, 124. Thus, each partition 110, 120 has its OS and, e.g., a recognition application domain located on top of the OS. The various timing constraints for tasks, the OS scheduler, and the mapping constraints (i.e., assignment of tasks and schedulers to specific cores) are defined, visualized, verified, and verified.

[0019] The application layer is generally a complex software layer that performs a set function or responds to a set of inputs. Application programs 114, 124 are generally called through an operating system 112, 122, such as an RTOS, which itself is designed to guarantee latency and provide deterministic behavior. The RTOS 112 and preferred applications 114 are typically interfaced to a hardware driver library built to preferred design standards. The driver layer guarantees latency and determinism through the structure of an application programming interface (API) that defines the functionality of the application program calls. The design of the API with the priority constraints sets the foundation for higher level software and acts as a system design constraint designed to guarantee the preferred behavior.

[0020] FIG. 2 illustrates timing for performing operations 200 in accordance with at least one embodiment.

[0021] In FIG. 2, events 210 are plotted against time 220 according to at least one embodiment. As an action is taken, events 230 are captured. At first glance, the events appear to be distributed at random times. However, depending on the software sampling, the events 230 are clustered approximately around a given time. In FIG. 2, the events 230 are distributed within a predefined time boundary 240, for example, 1 millisecond (ms). The time boundary 240 for the events 230 in FIG. 2 is clustered in a 1 ms window 240 from 5 ms 242 to 6 ms 244. However, an event can occur outside the cluster, for example, event 250 at 10 ms.

[0022] In operation, the processor employs a context switch for a time boundary of, for example, 1 millisecond. An event starts, the operating system makes the context switch do something, and then the process returns to performing the action. Thus, the context switch can take a relatively large amount of time, for example, the total time can take 10 milliseconds. In the priority system, an attempt is made to remove delays and outliers, for example, an event 250 at 10 ms. For example, the priority software can involve an autonomous vehicle, a robot, a medical device, or the like, where the inability to predict whether an event is going to take 1 millisecond or 10 milliseconds creates problems. For the priority software, this unpredictable delay can cause serious damage or injury to property or people, examples of this would be a car switching from autonomous to manual mode and the driver not being prepared, a robot acting to kill or injure someone, etc.

[0023] The priority system is upgraded to prevent reliability problems caused by delays. In contrast, with a mobile phone or laptop computer, this situation occurs all the time. For example, in response to a user scrolling in a browser, the scrolling process may hang for a period of time before continuing. The user may observe this phenomenon, but continue scrolling. However, with priority applications, this type of glitch cannot occur, so that the above-mentioned problems, such as causing damage or injury, are avoided.

[0024] In many cases, software is designed to run as quickly as possible. However, for priority software, the goal is reliability, e.g., tasks should be completed consistently and within a given time frame 240, e.g., 1 millisecond, to prevent adverse effects on safety or operations. Furthermore, in reality, there are various tasks that are executed sequentially and simultaneously.

[0025] FIG. 3 illustrates a number of tasks completed by an executive unit 300 in accordance with at least one embodiment.

[0026] In FIG. 3, an executive schedules tasks or operations. Completion of a task is often referred to as an event. An executive 310, e.g., a CPU or multiple cores in a multi-core processor, schedules tasks 320 in succession. There may be dependencies 322, 324 between tasks, and one task 326 often produces data that is used by the next task 328. This creates an order of dependencies, where the time bounds for the execution of a task are a predefined amount of time 330, e.g., a task should be executed within 100 milliseconds (ms). The 1 ms bounds 340 of a task may include a start error bound 342 and an end error bound 344 that define a period during which the task may start and finish, and all complete execution of the task should be completed within the 100 ms time bounds 330.

[0027] Thus, often a cushion or leeway is built into the execution of the tasks, and there are time boundaries not only across the 100 ms 330, but also within individual tasks 320, and there are dependencies 322, 324 between tasks. For example, a first task 326 should be executed before a second task 328 can begin. Thus, the executive 310 schedules the tasks 320, for example in a real-time operating system (RTOS), such that the tasks are executed within the 100 ms time frame 330. A variance of 1 ms 340 is expressed between the start time and the end time. The start time and the end time bracket the amount of time of the modality, e.g., 1 ms 340. The 1 ms time boundary 240, 340 as shown with respect to FIG. 2 occurs, for example, between 5 ms 242 and 6 ms 244.

[0028] FIG. 4 illustrates two modalities 400 according to at least one embodiment.

[0029] In FIG. 4, a first group of events 410 are clustered in a 1 ms time boundary 1 (mode 1 412) from 5 ms 414 to 6 ms 416. A second group of events 420 are clustered in a 1 ms time boundary 2 (mode 2 422) from 10 ms 424 to 11 ms 426. However, one skilled in the art will appreciate that other modalities can occur. Thus, in the real world, there is not always a single modality, but often multi-modality. Thus, mode 1 412 occurs within 1 millisecond from 5 ms 414 to 6 ms 416, and mode 2 422 occurs in milliseconds from 10 ms 424 to 11 ms 426. However, there is uncertainty as to which mode occurs. The two modes 412, 422 can occur when the software is running continuously, or occur when functionality is added somewhere in the software, but not necessarily in the running software. The various modalities can occur as the software is compiled once and sent to the vehicle, where only one mode is modified, however, upon compiling and re-running other portions of the software, mode 2 422 can be realized.

[0030] Thus, as described below, variants or non-determinism are added to the software to identify timing problems or force the occurrence of previously unknown modalities. Forcing modalities increases the likelihood of identifying problems during development testing, thus increasing safety even if the modality has a low statistical chance of occurring during production or after the software is deployed. Dynamic application of randomness by deliberately inserting non-determinism is used to attempt to break the software to identify the problem.

[0031] FIG. 5 illustrates a memory alignment randomization 500 according to at least one embodiment.

[0032] In Figure 5, the memory layout of the software is randomized such that the order of execution of the software is changed from one execution to another to reveal modalities. However, memory allocation in the software involves pre-allocation of a number of linearly allocated memory or scratch buffers.

[0033] 5 shows a memory 510 that is allocated four inputs, e.g., input 1 512, input 2 514, input 3 516, and input 4 518, in response to a particular operation. In response to the fifth input being accessed, the software crashes. The software successively allocates input 1 512, then input 2 514, then input 3 516, then input 4 518. This makes the allocations fully predictable. Any kind of cache effect or how caches are functioning or interacting will manifest in a predictable way in the circumstances.

[0034] Intentional non-determinism can be added in pieces of software that change timing in hardware. One example is address space layout randomization, where this security measure tends to expose modalities in software timing because caches in hardware (data caches, TLBs, branch predictions, etc.) tend to change when there is "false sharing" or "true sharing", which in turn depends on how ASLR chooses to align addresses (virtual or physical). True sharing of data occurs when two cores try to access and modify the same word, resulting in successive invalidations of the cache line in the other core. "False sharing of data" occurs when two cores try to access and modify two different words in the same cache line, resulting in successive invalidations of the cache line in the other core.

[0035] Thus, according to at least one embodiment, the allocation order of memory 520 is randomized for both testing and production, so that instead of assigning input 1 512, input 2 514, input 3 516, input 4 518 sequentially as shown in memory 510, a random or pseudo-random number generator 530 is used to provide variation to the order in which the allocation occurs to enforce adherence to modality. For example, with randomization, memory 520 is assigned in the order: input 3 522, input 1 524, input 4 526, then input 2 528.

[0036] For example, different modes are due to changes to page alignment when an executable is placed in memory. Thus, no code has changed, but when code is placed in memory, it results in a mode change. The reason for the mode change is that a change occurs due to the way caches work in the hardware. Mode changes can occur not only due to recompilation, but also due to running on different hardware.

[0037] Thus, the use of ASLR and more 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 enforce exposure of areas of modal behavior. Another example is when assigning hashing algorithms or constants to associative containers.

[0038] The software can also be executed on two advanced Reduced Instruction Set Computer (RISC) Machine (ARM) CPUs, where the ARM CPUs are different versions. The same time boundaries can be used, but on different hardware, the software runs in various modes.

[0039] For vehicles, manufacturers strive to have a single mode, and by having multiple modes, they exceed their budget. For example, they build two modes and calculate the worst case behavior for the two modes. However, timings are overestimated, which results in budget overruns. Software components have multiple worst cases stacked together, which leads to even further overestimation.

[0040] Knowledge of the modes that occur and how the software executes is used to allow software to be updated over time. Knowledge of the different modes is useful for using the software on different versions of hardware, but the times at which the modes occur may vary.

[0041] Typically, for priority software such as self-driving software, robots, medical devices, nuclear plants, airplanes, and the like, the software is developed and then specifically tested for the purposes it is intended for and the situations it will experience. The current industry best approach to safety is to write the software and then prevent anything in the critical software from being changed.

[0042] In contrast, according to at least one embodiment, changes are built into the entire development process, for example as described with respect to the randomization of memory allocation described with reference to FIG. 5. This causes mode shifts from one place to another. Any slight change can end up being a tailspin, where the software does not meet timing constraints, e.g., execution timing does not fit within the 100 millisecond boundary. The goal according to at least one embodiment is to increase the quality of the software, reduce the cost, and allow the software to be delivered faster, which includes in part reusing the software over time and updating the software over time. In order to update the software over time, aspects of the software cannot be fixed in a foundation that prevents the software from being changed. By accepting that changes will be made, it must also be accepted that there is multimodal software. Thus, the multimodality problem must be solved early, otherwise any change to the software is a big nuisance, because it will cause timing changes or cause untested and unpredictable effects. Thus, multimodality is exercised early in the development process.

[0043] Thus, when software is developed, variants are forced to arise, so that the software is constructed in a resilient manner, forcing bands of unknowns to arise, whereby fixes are developed to address previously unknown problems. Such variations often come in the form of small changes. Because variants are forced into the software, the software encounters situations that it would not normally encounter.

[0044] Building variability into software is similar to a concept called TAKT time, which involves aligning the manufacturing process with customer demand. TAKT time is a metric that represents the calculation of the available production time divided by customer demand. For example, if a factory operates 480 minutes per day and a customer requests 240 products per day, the TAKT time is 2 minutes. Similarly, if a customer wants two new products in January, the TAKT time is 2 weeks. The objective is to precisely match production to demand. There is also a concept called Chaos Monkey, which is a resilient tool that helps applications tolerate random instance defects. Production plots are drawn periodically to recognize what is occurring and prevent the production process from being interrupted. Variability or defects are introduced into the production environment to tolerate defects. According to at least one embodiment, variants are built into the software development process as a testing process for the timing of the software. Events that occur 1% of the time, such as 0.0001% of the time events, cannot be avoided.

[0045] FIG. 6 illustrates a critical path 600 of events with dependencies in accordance with at least one embodiment.

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

[0047] The critical path can be identified, the critical path is given priority, and the execution of other task orders is shifted and changed. The reordering of tasks can be changed statically, one time, or dynamically. The critical path is the most important path, i.e., the path that takes the longest to complete.

[0048] In Figure 6, first event 1 640 occurs. 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. Event 9 650 is also scheduled after event 5 612 and event 6 622. Then event 10 660 is completed after event 9 650. There are various places where variations can be added. Not all tasks have dependencies on each other. Non-dependent tasks occur as scheduled consecutively for convenience. Eventually, a task supplies its output to other dependent tasks.

[0049] In FIG. 6, the critical path is path 670. As shown in FIG. 6, the critical path 670 includes event 1 640, event 3 630, event 7 632, event 8 634, event 9 650, and event 10 660. Because the critical path 670 is the path with the longest execution time, the tasks in the critical path 670 cannot be reordered. However, the order of the other tasks can be rearranged. For example, event 5 612 can be scheduled with event 7 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 or event 8 634, and event 4 620 can be scheduled with event 3 630 or event 7 632. Reordering the execution of those tasks will affect the variance of the critical path.

[0050] When a task executes linearly, other tasks may cycle around the critical path 670 or change execution on other CPUs. For systems with multiple execution units, the order of execution may change. This may force cache effects or expose execution modalities.

[0051] Enforcing modality increases the likelihood of identifying issues during development testing, thus increasing safety even if the statistical probability of the modality occurring during production or after the software is deployed is low. Applying randomness to reorder events is accomplished by intentionally inserting non-determinism and constantly trying to dynamically interrupt the software to identify issues. As stated, the issue occurs 0.0001% of the time, and adding non-determinism makes the issue occur more frequently than 0.0001%, e.g., 0.01%, so that the issue can be addressed before production and before the software is deployed.

[0052] Another aspect is that software reuse is enabled, e.g., the software can evolve over time. For example, the current version of the software does not have problems. However, variations can be built into the software's execution, and as a result, possible modalities can be explored as software changes are made. Non-deterministic randomness is introduced during testing and production to account for and manage future changes and to optimize hardware allocation.

[0053] The introduction of nondeterminism provides tolerance beyond what is actually specified, e.g., the software is not over-provisioned. When software is changed or an upgrade is implemented, the software is tested by introducing nondeterminism to ensure that problems do not arise. The introduction of nondeterminism not only prevents over-engineering of hardware, but also prevents over-fitting current software to current hardware.

[0054] For example, hardware is changed and software is reused when a new vehicle is created. Software is created for new hardware. If the new software is kept constant, e.g., no changes are allowed, when the new software is used on the new hardware, the new hardware will be overfitted to the software. Instead, the introduction of non-determinism provides a broader view of the modality, and safety is guaranteed by careful planning and deployment of a complete understanding of the hardware and software.

[0055] FIG. 7 illustrates three modalities 700 according to at least one embodiment.

[0056] In Figure 7, the timing constraint is 100 ms 710. A first group of events 720 are clustered at time boundary 1 (mode 1 724) of 1 ms 722. A second group of events 730 are clustered at time boundary 2 (mode 2 734) of 1 ms 732. A third group of events 740 are clustered at time boundary 3 (mode 3 744) of 1 ms 742.

[0057] Subcomponent 0 750, subcomponent 1 751, subcomponent 2 752, subcomponent 3 753, subcomponent 4 754, subcomponent 5 755, subcomponent 6 756, and subcomponent 7 757 are shown below the plot. Instead of measuring subcomponents 0-7 750-757 individually, the overall execution timing for subcomponents 0-7 750-757 is measured. The order of execution is changed and a modal distribution is captured.

[0058] When events are randomized, multiple modes are exposed and stacked. The right mode, mode 3 744, is very rare in normal execution, but randomization has exposed mode 3 744. A software developer can attempt to avoid mode 3 744, so the software developer inspects the software to determine why mode 3 744 occurred, e.g., which subcomponents 0-7 750-757 were part of the critical path. A distribution plot showing the three modalities 700 informs the software developer where time should be spent to optimize execution, reduce variability, etc., so mode 3 744 can be shifted to the left so variability is not too close to the 100 ms time constraint 710 to ensure safety.

[0059] According to at least one embodiment, the software and hardware are separated. Thus, the hardware can be floating point, the software can be floating point, or both. Due to the nature of the system, one does not disrupt the other. Thus, the software is not put into production in response to a software disruption, or the software is rolled back very quickly because testing can reveal the critical edge case. By eliminating unspecified modalities, e.g., modalities that are outside or too close to the design timing constraints, e.g., mode 3 744, true safety planning and mitigation issues are addressed even as the system becomes more and more complex.

[0060] Through identification of edge cases, e.g., mode 3 744, the quality of the software is ensured along with the compatibility of the software with the relevant hardware. Both the complexity in the static model and the complexity in the dynamic model, both in terms of software and hardware, where both are changing, are considered. This is applicable not only to the evolution of a particular model line, but also to variations within that model line in completely different models. Insight is not required in all the details of the software and hardware to mitigate risk.

[0061] Randomization can be introduced into software in a number of ways: Randomization can be introduced based on the order in which events are scheduled taking into account dependencies as described with reference to Figure 6. As mentioned above, current software development practices are to prevent any variation.

[0062] The allocation order can also be randomized as described with respect to Figure 5. Other randomization techniques include oversized allocations (allocations in excess of requests), code allocations, use of various instructions, and the like.

[0063] For example, software instructions are generated to perform a set of tasks. In many cases, the instructions are equivalent or at least produce the same result. For this, various instructions are available; for example, for x86 systems, there are similar instructions such as add, load effective address (LEA), etc. LEA runs on different execution units, introducing some amount of variants in the execution because it uses different resources. Also, various instructions that are equivalent for a given purpose can be selected that produce different results. For example, for floating point math, a version using 16-bit floating point instructions (called F16) and a version using 32-bit floating point instructions (called F32) are available.

[0064] 8a-8b illustrate the effect of introducing timing variations into API calls and responses 800 in accordance with at least one embodiment.

[0065] In Fig. 8a, events for requests 1-3 810, 820, 830 and events for responses 1-3 812, 822, 832 are shown. During software testing, the virtual hardware can simulate timing-critical failures in the system by enumerating all timing APIs where race conditions can occur. An event represents an execution instance of a statement or a sequence of statements in a program. An event specifies a set of shared memory locations that are read and / or written. Events do not necessarily occur instantaneously, and in parallel programs, events can be out of order. The timing of an event is specified by its start and end instants. Events e1, e2 are simultaneous if the start of e1 occurs after the start of e2 but before the end of e2, or vice versa. The tracing feature helps to isolate system problems by monitoring selected system events.

[0066] 8, Request 1 810 occurring between t0 812 and t1 814 represents a request for deceleration for a vehicle, e.g., a rail car, a passenger car, and the like. However, one of ordinary skill in the art will appreciate that other implementations consistent with the embodiments disclosed herein are applicable. Response 1 812 occurring between t1 814 and t2 822 represents a deceleration applied to the vehicle.

[0067] Request 2 820, occurring between t2 822 and t3 824, represents a request for identification of a track switch deceleration for a vehicle (in this example, the vehicle is a rail car). Response 2 822, occurring between t3 824 and t4 832, represents the location of the track switch being identified.

[0068] Request 3 830 occurring between t4 832 and t5 834 represents a request for a vehicle track switch to occur at the identified track switch location. Response 3 832 occurring between t5 834 and t6 836 represents a vehicle track switch to be implemented at the identified track switch location.

[0069] In different executions of the same program on the same input, the access events that constitute a conflict may occur in different orders, which may result in different program behavior (non-determinism). For example, multiple threads may access the same variable in a shared memory simultaneously, and at least one access may modify the variable, which may result in an error.

[0070] An application programming interface (API) is a defined set of rules that allows different applications to communicate with each other. For example, memory management APIs are used to allocate memory, data management APIs are used to access data, and socket APIs are used to provide a form of inter-process communication (IPC) and send messages across networks. Many other types of APIs exist.

[0071] APIs designed for real-time rendering employ a pipeline execution model. A race condition refers to a bug that arises due to the timing or order of execution of multiple operations. A bug is an error, flaw, or deficiency in the design, development, or operation of computer software that causes the computer software to produce incorrect or unexpected results or to behave in an unintended manner. A race condition is a very broad class of bug that can manifest itself in very different ways depending on the problem space. For example, multiple threads making multiple API calls using the same resource may produce different results due to the timing of the API.

[0072] In Figure 8b, fault injection for possible interleaving between API operations involves introducing defects into the software to identify timing issues. Formal methods can be used to identify parts of the software on which timing depends, and then enumerate all potential execution paths. This then leads to the identification of all potential failure modes, and creates a test plan in which all of the failure modes must be tested (either automatically or manually).

[0073] Figure 8b again depicts the command to slow down the vehicle, showing Request 1 850 occurring between t0 852 and t1 854. Response 1 852, occurring between t1 854 and t2 862, represents the vehicle deceleration being initiated.

[0074] Variation has been added such that Request2 860, Response2 862, Request3 870, and Response3 872 are shifted in time, thereby creating race conditions between Request2 860 and Request3 870, and between Response2 862 and Response3 872.

[0075] Here, Request 2 860 occurs between t1 854 and t2 862 and represents a request for identification of a track switch deceleration for the vehicle. Here, Response 2 862 occurs between t2 862 and t3 864 and represents the location of the track switch being identified.

[0076] Here, request 3 870 occurs between t1 854 and t2 862 and represents a request for a vehicle track switch to be performed at an identified track switch location. Here, response 3 872 occurs between t2 862 and t3 864 and represents a vehicle track switch to be implemented at an identified track switch location. However, request 3 870 for a track switch to be performed at an identified track switch location is simultaneous with request 2 860 for identification of a vehicle track switch deceleration. Similarly, response 3 872 for performing a track switch at an identified track switch location is simultaneous with response 2 862 for identifying the track switch location. Thus, the track switch at request 3 870 and response 3 872 cannot be performed because response 2 862 has not been completed and the identification of the track switch location is not known before the track switch operation is performed.

[0077] By adding this source of non-determinism, the modal behavior is quantified and timing bounds for the various implementations are determined. This quantification allows discovery of the pieces of software / hardware that are different, ensuring that all of these are within the operational design domain of the system. A complete list of timing issues (e.g., in a fully formal manner) also provides a "timing coverage" for the system, identifying how many timing modalities have been implemented and quantified. Estimates can be identified that indicate worst-case bounds for modalities that have not been implemented (uncovered modalities).

[0078] The software can also be modified in production to identify if the real world software ever experiences timings that do not match the developed model. Any exceedances can be reported and an investigation can be initiated to understand why the model was wrong. Furthermore, attention can be paid not only to unexpected exceedances, but also to the distribution curve of expected runtime execution behavior. In response to the runtime not matching the expected statistical model, an investigation can be initiated again. Tests can be performed virtually with varying fidelity to the hardware. The fidelity level of the simulation / emulation is related to the establishment of the model, and more accurate virtual tests can be used to quantify the fidelity of the less accurate model. Thus, timing variability can be managed and multi-modal behaviors are exposed. As software and hardware evolve, new modalities may arise. The above method can identify when new modalities arise and the change in the range of possible behaviors and possible new failure paths can be quantified. Hypothetical hardware can be created that exhibits other behaviors and exposes other modalities. Identification of unspecified modalities and bad paths makes the creation of new hardware easier because the risk that timing will be an issue on this new platform is reduced by having the scale of timing changes known in advance.

[0079] To further improve upon the above, some types of algorithms are more efficient with synchronization on certain timing events. For example, direct networking to RAM is more efficient with timing well quantified. Similarly, operating system schedulers can reduce timing variability as the scheduler is tuned, which requires quantification of potential variability as described above. Such optimization is similar to interference reduction for safety systems, also known as non-interference. Additionally, some algorithms such as RCU (read copy update) work better (especially in real-time operating systems) with custom quiescent points to reclaim memory as soon as possible. By having the system quantify the timing variance, it is possible to discover how to optimally schedule and insert quiescent points while still meeting other criteria for the overall system.

[0080] FIG. 9 is a flowchart 900 of a method for providing timing independence to software in accordance with at least one embodiment.

[0081] In FIG. 9, the method starts at S902 and at S910, variation is added to the software. With reference to FIG. 4, variants or non-determinism are added to the software to identify timing issues or force the occurrence of previously unknown modalities. Forcing modalities increases the likelihood of identifying issues during development testing, thus increasing safety even if the statistical probability of the modality occurring during production or after the software is deployed is low. Dynamic application of randomness by intentionally inserting non-determinism is used to attempt to disrupt the software to identify the issue. With reference to FIG. 5, the memory layout of the software is randomized such that the order of execution of the software is changed from one execution to another to reveal modalities. With reference to FIG. 7, other randomization techniques include oversized allocations, code allocations, use of different instructions, and the like.

[0082] At S914, the distribution of unspecified modalities associated with the software is identified. With reference to FIG. 7, by removing unspecified modalities, e.g., modalities that are outside of the design timing constraints, true safety planning and mitigation issues are addressed even as the system becomes increasingly complex. With reference to FIG. 8a-8b, by adding the sources of non-determinism, the modal behavior is quantified and the timing ranges for various executions are determined. This quantification allows for the discovery of the pieces of software / hardware that are different and ensures that all of these are within the operational design domain of the system. With reference to FIG. 6, the critical path can be identified, the critical path is prioritized, and the execution of other task orders is shifted and changed. The reordering of tasks can be changed either statically one time or dynamically.

[0083] At S918, at least a portion of the software is modified to remove unspecified modalities. With reference to FIG. 6, the introduction of nondeterminism provides tolerance beyond what is actually specified, e.g., the software is not over-provisioned. When the software is changed or an upgrade is implemented, the software is tested by introducing nondeterminism to ensure that no problems arise. The introduction of nondeterminism not only prevents over-engineering of the hardware, but also prevents over-fitting the current software to the current hardware. With reference to FIG. 7, the distribution plot informs the software developer when time should be spent to optimize execution, reduce variance, etc., so that mode 3 can be shifted left so that variance is not too close to the 100 ms time constraint to ensure safety.

[0084] The process then ends at S920.

[0085] At least one embodiment of a method for providing timing independence to software includes adding variation to the software, identifying a distribution of unspecified modalities associated with the software, and modifying at least a portion of the software to remove the unspecified modalities.

[0086] FIG. 10 is a high-level functional block diagram of a processor-based system 1000 according to at least one embodiment.

[0087] In at least one embodiment, the processing circuit 1000 provides timing independence to software. The processing circuit 1000 implements the addition of timing independence to the software using the processor 1002. The processing circuit 1000 also includes a non-transitory computer-readable storage medium 1004 that is used to implement the timing independence in the software. In particular, the non-transitory computer-readable storage medium 1004 is encoded with, i.e., stores, instructions 1006, i.e., computer program code, that are executed by the processor 1002 to cause the processor 1002 to perform operations that provide timing independence to the software. The execution of the instructions 1006 by the processor 1002 (at least in part) represents an application that implements at least a portion of the methods described herein (hereinafter, processes and / or methods described) in accordance with one or more embodiments.

[0088] 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 by 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 such that the processor 1002 and the non-transitory computer readable storage medium 1004 connect 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 to enable the processing circuit 1000 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.

[0089] The processing circuit 1000 includes an I / O interface 1010. The I / O interface 1010 is coupled to external circuitry. In one or more embodiments, the I / O interface 1010 includes a keyboard, a keypad, a mouse, a trackball, a trackpad, a touch screen, and / or cursor direction keys to communicate information and commands to the processor 1002.

[0090] The processing circuit 1000 also includes a network interface 1012 coupled to the processor 1002. The network interface 1012 enables the processing circuit 1000 to communicate with a network 1014 to which one or more other computer systems are connected. The network interface 1012 may include a wireless network interface, such as Bluetooth, Wi-Fi, Worldwide Interoperable 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.

[0091] The processing circuit 1000 is configured to receive information through an I / O interface 1010. The information received through the I / O interface 1010 includes one or more of instructions, data, design rules, a library of cells, and / or other parameters for processing by the processor 1002. The information is transferred to the processor 1002 via a bus 1008. The processing circuit 1000 is configured to receive information related to a user interface (UI) through the I / O interface 1010. The information is stored in the non-transitory computer-readable storage medium 1004 as a UI 1020.

[0092] In one or more embodiments, one or more non-transitory computer-readable storage media 1004 have stored thereon (in compressed or uncompressed form) instructions 1006 that can be used to program a computer, processor, (or other electronic device) to perform a process or method described herein. The one or more non-transitory computer-readable storage media 1004 include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like.

[0093] For example, the non-transitory computer readable storage medium 1004 may include, but is not limited to, a hard drive, a floppy diskette, 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 or optical card, a solid-state memory device, or other type of physical medium suitable for storing electronic instructions. In one or more embodiments using an optical disk, the one or more non-transitory computer readable storage media 1004 includes a compact disk read-only memory (CD-ROM), a compact disk read / write (CD-R / W), and / or a digital video disk (DVD).

[0094] 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 algorithms, that facilitate performing at least a portion of the process and / or method for providing timing independence to software.

[0095] Thus, in at least one embodiment, the processor 1002 executes instructions 1006 stored in one or more non-transitory computer-readable storage media 1004 to load, execute, and operate the software under test 1030. The processor 1002 adds variation 1032 to the software, including non-determinism and randomization (e.g., randomizing memory allocation, oversizing memory allocation, or various equivalent instructions). The processor 1002 executes instructions 1006 stored in one or more non-transitory computer-readable storage media 1004 to determine distributions 1034 of unspecified modalities, e.g., distributions for modalities that are outside of the design timing constraints 1036 of the software. The processor 1002 determines timing bounds 1038 for the execution of tasks and determines events in the critical path and non-dependent tasks 1040 that are not in the critical path. The processor 1002 can reorder the non-dependent tasks 1040 that are not in the critical path. The processor 1002 implements modifications 1042 to the software to prevent over-engineering of the implemented hardware and over-fitting the software to the implemented hardware. The processor 1002 optimizes the execution 1044 of the tasks of the software. The display 1070 provides a user interface (UI) 1072 that presents the software, the distribution of modalities, variances added to the software, timing ranges, and events, tasks, and paths 1074.

[0096] Separate instances of these programs may be running on or distributed among any number of separate computer systems. Thus, although particular steps are described as being performed by particular devices, software programs, processes, or entities, this is not required. Various alternative implementations will be appreciated by those skilled in the art.

[0097] Moreover, those skilled in the art will readily appreciate that the above-described techniques may be utilized in a variety of devices, environments, and contexts. Although the embodiments have been described in terms specific to structural features or method acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. 1. A method for providing timing independence to software, comprising: Adding variation to the software; identifying a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; A method comprising:

2. The method of claim 1 , wherein the identifying the distribution of the unspecified modalities associated with the software comprises identifying the distribution of modalities that are outside of design timing constraints of the software.

3. said adding said variation to said software comprising: adding non-determinism to the software so as to change the timing of the execution of tasks by the software; or adding randomization to the software; 3. The method of claim 1 or 2, wherein the adding of the randomization to the software includes at least one of adding randomization of memory allocation, oversizing allocation of memory, or replacing instructions of the software with different equivalent instructions.

4. 3. The method of claim 1 or 2, wherein the identifying the distribution of the unspecified modalities comprises quantifying the unspecified modalities, determining a timing range for execution of a task of the software, and identifying the unspecified modalities at the ends of the timing range.

5. 3. The method of claim 1, wherein the identifying the distribution of the unspecified modality comprises identifying events in a critical path and rearranging an order of execution of non-dependent tasks that are not in the critical path.

6. 3. The method of claim 1 or 2, wherein the modifying of the at least a portion of the software to remove the unspecified modality comprises modifying the at least a portion of the software to prevent over-engineering of implemented hardware and over-fitting of software to the implemented hardware.

7. The method of claim 1 or 2, wherein the modifying of the at least part of the software to remove the non-specific modality comprises optimizing the execution of a task of the software.

8. 1. An apparatus for providing timing independence to software, comprising: A memory storing computer readable instructions; a processor coupled to the memory; wherein the processor executes the computer readable instructions to Adding variation to the software; identifying a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; The apparatus is configured to perform the operations of.

9. 10. The apparatus of claim 8, wherein the processor is further configured to identify the distribution of the unspecified modalities associated with the software by identifying the distribution of modalities that are outside of design timing constraints of the software.

10. The processor further comprises: adding non-determinism to the software so as to change the timing of the execution of tasks by the software; or adding randomization to the software; 10. The apparatus of claim 8 or 9, wherein the adding of the randomization to the software comprises at least one of adding randomization of memory allocation, oversizing allocation of memory, or replacing instructions of the software with different equivalent instructions.

11. 10. The apparatus of claim 8 or 9, wherein the processor is further configured to identify the distribution of the unspecified modalities by quantifying the unspecified modalities, determining a timing range for execution of a task of the software, and identifying the unspecified modalities at the ends of the timing range.

12. 10. The apparatus of claim 8 or 9, wherein the processor is further configured to identify the distribution of the unspecified modality by identifying events in a critical path and rearranging an order of execution of non-dependent tasks that are not in the critical path.

13. 10. The apparatus of claim 8 or 9, wherein the processor is further configured to modify the at least a portion of the software to remove the unspecified modality by modifying the at least a portion of the software to prevent over-engineering of implemented hardware and over-fitting of the software to the implemented hardware.

14. 10. The apparatus of claim 8 or 9, wherein the processor is further configured to modify the at least part of the software to remove the unspecified modality by optimizing execution of the tasks of the software.

15. A non-transitory computer readable medium having computer readable instructions stored thereon, the computer readable instructions, when executed by a processor, Adding variation to the software; identifying a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; A non-transitory computer-readable medium that causes the processor to perform operations including:

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

17. said adding said variation to said software comprising: adding non-determinism to the software so as to change the timing of the execution of tasks by the software; or 17. The non-transitory computer readable medium of claim 15 or 16, further comprising at least one of adding randomization to the software, the adding randomization to the software comprising at least one of adding randomization of memory allocation, oversizing allocation of memory, or replacing instructions of the software with different equivalent instructions.

18. The identification of the distribution of the unspecified modality comprises: quantification of the unspecified modalities, determining timing ranges for execution of tasks of the software, and identifying the unspecified modalities at the ends of the timing ranges; or identifying events in a critical path and rearranging the order of execution of non-dependent tasks that are not in the critical path; 17. The non-transitory computer readable medium of claim 15 or 16, comprising at least one of:

19. 17. The non-transitory computer-readable medium of claim 15 or 16, wherein the modifying of the at least a portion of the software to remove the unspecified modality comprises modifying the at least a portion of the software to prevent over-engineering of implemented hardware and over-fitting of software to the implemented hardware.

20. 17. The non-transitory computer readable medium of claim 15 or 16, wherein the modifying of the at least part of the software to remove the non-specific modality comprises optimizing the execution of a task of the software.

Images