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 it. [Background technology]

[0002] Software has historically been executed in a way that minimizes sources of variation in terms of execution time. By minimizing sources of variation, it becomes easier to achieve reliability for the entire system. For example, bounding execution time is a common requirement (e.g., a braking system must apply the brakes within a specific number of milliseconds). Execution time variation also means that multiple systems can interleave their interactions in complex ways, making observable combinatorial execution difficult to fully predict, creating a larger state space for correctness analysis, and for examining more possible failure paths. However, this approach means that 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] As vehicles begin to use more non-real-time hardware and operating systems to meet certain standards, traditional approaches to timing become less practical, hindering software reuse and deployment.

[0004] As well as meeting software quality goals, it is still preferable to decouple software 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 stored thereon computer-readable instructions 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 explanation of the drawings]

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

[0009] [Figure 1] Figure 1 shows a system that implements safety-critical and general-purpose applications. [Figure 2] FIG. 2 illustrates timing for performing operations according to at least one embodiment. [Figure 3] FIG. 3 illustrates a number of tasks completed by an executive unit according to at least one embodiment. [Figure 4]FIG. 4 illustrates two modalities according to at least one embodiment. [Figure 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 according to 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 according to at least one embodiment. [Figure 8b] FIG. 8b illustrates the effect of introducing timing variations into API calls and responses according to at least one embodiment. [Figure 9] FIG. 9 is a flowchart of a method for providing timing independence to software according to at least one embodiment. [Figure 10] FIG. 10 is a high-level functional block diagram of a processor-based system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] The embodiments described herein set forth 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, in the following description, a reference to forming a first feature above or on a second feature includes embodiments in which the first and second features are formed in direct contact, as well as 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. Additionally, the present disclosure repeats reference numerals 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 than," "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 shown in the figures. 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 listed along with methods by 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 a plot of time versus frequency of events is captured. For example, 100 milliseconds is provided in the design of the software, which 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 to the software impacts timing by moving it 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 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 combinatorial complexity, which prevents timing changes for trials that always only expose one possible execution. However, modern superscalar hardware essentially runs through guesswork 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 simply to intentionally add more variability in the timing during testing, or even during production runs.

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

[0018] In FIG. 1 , different partitions 110, 120 are configured to separate various application domains, i.e., merge mixed-criticality applications, and utilize hardware resources as efficiently as possible. A real-time operating system (RTOS) 112 can be used to call priority applications 114. General-purpose applications 124 can run using an operating system 122, e.g., an RTOS or a more general operating system such as the Windows® operating system or the Linux® operating system. Separate processors or multi-core processors 130 can be used to execute applications 114, 124. Thus, each partition 110, 120 has its own OS and, e.g., a recognized application domain located on top of the OS. Various timing constraints for tasks, OS schedulers, and mapping constraints (i.e., assigning tasks and schedulers to specific cores) can be 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 typically interface with 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 using precedence constraints sets the foundation for higher-level software and serves as system design constraints designed to guarantee preferred behavior.

[0020] FIG. 2 illustrates timing for performing operations 200 according to at least one embodiment.

[0021] In Figure 2, events 210 are plotted against time 220 according to at least one embodiment. As actions are performed, 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 Figure 2, the events 230 are distributed within a predetermined time boundary 240, for example, 1 millisecond (ms). The time boundary 240 for the events 230 in Figure 2 is clustered in a 1 ms window 240 from 5 ms 242 to 6 ms 244. However, an event, for example, event 250 at 10 ms, can occur outside the cluster.

[0022] In operation, a processor employs a context switch for a time boundary, e.g., 1 millisecond. An event begins, the operating system causes the context switch to do something, and then the process returns to executing the action. Therefore, a context switch can take a relatively large amount of time, e.g., a total time of 10 milliseconds. A priority system attempts to eliminate delays and outliers, e.g., events 250 at 10 milliseconds. For example, priority software may involve autonomous vehicles, robots, medical devices, or the like, where the inability to predict whether an event is going to take 1 millisecond or 10 milliseconds creates problems. For priority software, this unpredictable delay can result in serious damage or injury to property or people; examples of this include a car switching from autonomous mode to manual mode and the driver not being prepared, or a robot acting in a way that kills or injures 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; for example, tasks should be completed consistently 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 run serially and simultaneously.

[0025] FIG. 3 illustrates several tasks completed by an executive unit 300 according to 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, sequentially schedules tasks 320. Dependencies 322, 324 may exist between tasks, with one task 326 often producing data used by the next task 328. This creates a dependency order, where the time boundary for the execution of a task is a predetermined amount of time 330; for example, a task should be executed within 100 milliseconds (ms). A task's 1-ms boundary 340 can include a start error boundary 342 and an end error boundary 344 that define the period within which the task may start and finish, and all complete execution of the task should be completed within the 100-ms time boundary 330.

[0027] Thus, cushions or leeway are often built into task execution, and time boundaries exist not only for the overall 100 ms 330 but also for individual tasks 320, and dependencies 322, 324 exist between tasks. For example, a first task 326 must execute before a second task 328 can begin. Thus, the execution unit 310 schedules the tasks 320, for example, in a real-time operating system (RTOS), so that the tasks execute within the 100 ms time frame 330. A 1 ms 340 variance is expressed between the start and end times. The start and end times bracket a modality's amount of time, 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 clusters in a 1 ms time boundary 1 (mode 1 412) from 5 ms 414 to 6 ms 416. A second group of events 420 clusters 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, a single modality is not always present; often, multiple modalities exist. 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 will occur. The two modes 412, 422 can occur when software is running continuously, or when functionality is added somewhere within the software, not necessarily within the running software. The various modalities can occur as the software is compiled once and sent to the vehicle, where only one mode is improved, however, as other portions of the software are compiled and re-run, mode 2 422 can be realized.

[0030] Thus, as described below, variants or nondeterminism are added to software to identify timing issues or force previously unknown modalities to occur. Forcing modalities increases the likelihood of identifying issues during development testing, thereby increasing safety even if the modality has a low statistical probability of occurring during production or after the software is deployed. Dynamic application of randomness by intentionally inserting nondeterminism is used to attempt to break the software in a way that identifies the issues.

[0031] FIG. 5 illustrates 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 large number of linearly allocated memory or scratch buffers.

[0033] 5 shows memory 510, which, depending on a particular operation, is allocated four inputs, e.g., input 1 512, input 2 514, input 3 516, and input 4 518. In response to the fifth input being accessed, the software crashes. The software sequentially 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 function or interact will manifest in a predictable way in that situation.

[0034] Intentional nondeterminism can be added in pieces of software that alter timing in hardware. One example is address space layout randomization; this security measure tends to expose modalities in software timing because caches in hardware (data caches, TLBs, branch predictors, 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 attempt 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 attempt 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 following order: input 3 522, input 1 524, input 4 526, then input 2 528.

[0036] For example, when an executable is placed in memory, different modes are due to changes to page alignment. 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] Therefore, using 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 run on two Advanced Reduced Instruction Set Computer (RISC) Machine (ARM) CPUs, where the ARM CPUs are different versions, and the same time boundaries are available, but on different hardware, the software runs in various modes.

[0039] For vehicles, manufacturers strive to have a single mode, and having multiple modes causes the manufacturer to exceed the budget. For example, a manufacturer may build two modes and calculate the worst-case behavior for the two modes. However, timing is overestimated, which results in a budget overrun. Software components have multiple worst-case scenarios 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 car software, robots, medical devices, nuclear plants, airplanes, and the like, the software is developed and then specifically tested for the purposes for which it is intended and the situations that the software 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 randomizing memory allocations described with reference to FIG. 5 , causing mode shifts from one location to another. Any slight change can ultimately lead to a tailspin, where the software does not meet timing constraints, e.g., execution timing does not fit within 100 millisecond boundaries. A goal according to at least one embodiment is to increase software quality, reduce costs, and enable faster delivery of software, which includes, in part, reusing software over time and updating software over time. To update software over time, aspects of the software cannot be fixed in a way that prevents the software from being changed. By accepting that changes will occur, it must also be accepted that multimodal software exists. For this reason, the multimodality problem must be resolved early; otherwise, any change to the software is a major nuisance because it will result in timing changes or untested, unpredictable effects. Therefore, multimodality is exercised early in the development process.

[0043] Thus, as software is developed, variants are forced into it, so that the software is built in a resilient way, forcing unknown bands to emerge, allowing fixes to be developed to address previously unknown problems. Such variations often take the form of small changes. Because variants are forced into the software, the software encounters situations that software 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 calculation of 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 two minutes. Similarly, if a customer wants two new products per month, the TAKT time is two weeks. The goal 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 periodically drawn to recognize what is occurring and prevent interruptions to the production process. 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 software timing. Events like 0.0001% of the time events occur 1% of the time, making them unavoidable.

[0045] FIG. 6 illustrates a critical path 600 of events with dependencies according to 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, prioritized, and the execution of other task orders shifted and changed. The reordering of tasks can be statically changed once or dynamically changed. 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 successively 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 , critical path 670 includes event 1 640, event 3 630, event 7 632, event 8 634, event 9 650, and event 10 660. Because critical path 670 is the path with the longest execution time, the tasks within critical path 670 cannot be reordered. However, the order of other tasks can be rearranged. For example, event 5 612 can be scheduled with either event 7 or event 8 634. Similarly, event 2 610 can be scheduled with either event 3 630 or event 7 632. Similarly, event 6 622 can be scheduled with either event 7 or event 8 634, and event 4 620 can be scheduled with either event 3 630 or event 7 632. Reordering the execution of these tasks affects the variability 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 can change. This may force cache effects or expose execution modalities.

[0051] Enforcing modality increases the likelihood of identifying issues during development testing, thereby increasing safety even if the statistical likelihood of the modality occurring during production or after the software is deployed is low. Applying randomness to reorder events is achieved by intentionally inserting nondeterminism and constantly seeking to dynamically disrupt the software to identify issues. As stated, the issue occurs 0.0001% of the time, and adding nondeterminism 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., software can evolve over time. For example, the current version of the software does not have any problems. However, as variations are built into the software's execution, 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] Introducing nondeterminism provides tolerance beyond what is actually specified, e.g., 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. Introducing nondeterminism not only prevents over-engineering of hardware, but also prevents over-fitting current software to current hardware.

[0054] For example, hardware is changed when a new vehicle is created, and software is reused. Software is created for new hardware. If the new software is kept constant, e.g., no changes are allowed, when new software is used on new hardware, the new hardware will be over-fitted to the software. Instead, the introduction of non-determinism provides a broader view of the modality, and safety is ensured by careful planning and deployment with 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 milliseconds 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 timing of all executions for subcomponents 0-7 750-757 is measured. The order of execution is changed to capture the modal distribution.

[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 exposes Mode 3 744. Software developers can attempt to avoid Mode 3 744 by inspecting the software to determine why Mode 3 744 occurred, for example, which subcomponents 0-7 750-757 were part of the critical path. The distribution plot showing the three modalities 700 informs the software developer where time should be spent to optimize execution, reduce variability, etc. Mode 3 744 can be shifted to the left so variability does not occur too close to the 100 millisecond time constraint 710 to ensure safety.

[0059] According to at least one embodiment, software and hardware are decoupled. Thus, either the hardware can be floating point, the software can be floating point, or both. Due to the nature of the system, one cannot 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 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 increasingly complex.

[0060] Through the identification of edge cases, e.g., Mode 3 744, the quality of the software along with its compatibility with related hardware is ensured. Both the complexity in the static model and the complexity in the dynamic model, where both software and hardware 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 into all the details of the software and hardware to mitigate risk.

[0061] Randomization can be introduced into software in several 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 allocation (allocation beyond request), code allocation, 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 reason, various instructions are available; for example, for x86 systems, similar instructions exist, such as add, load effective address (LEA), etc. LEAs run on different execution units, introducing some amount of variation in execution because they use different resources. Also, various instructions that are equivalent for a given purpose can be selected, producing different results. For example, for floating-point mathematics, versions using 16-bit floating-point instructions (called F16) and 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 according to at least one embodiment.

[0065] In Figure 8a, events for requests 1-3 810, 820, and 830 and events for responses 1-3 812, 822, and 832 are shown. During software testing, virtual hardware can simulate timing-critical failures in a system by enumerating all timing APIs where race conditions can occur. An event represents an execution instance of a statement or sequence of statements in a program. An event specifies a set of shared memory locations that are read from and / or written to. Events do not necessarily occur instantaneously; in parallel programs, events can be unordered. The timing of an event is specified by its start and end instants. Events e1 and 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 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, such as a rail car, passenger car, and the like. However, one skilled in the art will appreciate that other implementations consistent with 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 the 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 be performed 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 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 provide a form of inter-process communication (IPC) and are used to send messages across a network. Many other types of APIs exist.

[0071] APIs designed for real-time rendering employ a pipelined 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. Race conditions are a very broad class of bugs that can manifest themselves in widely different ways depending on the problem space. For example, multiple threads making multiple API calls using the same resource may produce different results depending on 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 the 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 852 represents the vehicle slowdown being initiated.

[0074] Variation has been added such that Request 2 860, Response 2 862, Request 3 870, and Response 3 872 are shifted in time, thereby creating race conditions between Request 2 860 and Request 3 870 and between Response 2 862 and Response 3 872.

[0075] Here, Request 2 860 occurs between t1 854 and t2 862 and represents a request for identification of a vehicle track switch deceleration. 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 occur 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 occur 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, which identifies the track switch location. Therefore, the track switch at request 3 870 and response 3 872 cannot occur because response 2 862 has not completed and the identity of the track switch location is not known before the track switch operation is performed.

[0077] By adding this source of nondeterminism, the modal behavior is quantified and timing bounds for various implementations are determined. This quantification allows for the discovery of the software / hardware pieces that are different and ensures 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 the "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 real-world software ever experiences timing that does not match the developed model. Any exceedances can be reported, and an investigation can be initiated to understand why the model was incorrect. Furthermore, attention can be paid not only to unexpected exceedances, but also to the distribution curve of expected runtime execution behavior. In response to runtime not matching the expected statistical model, an investigation can be initiated again. Testing can be performed virtually with varying fidelity to the hardware. The fidelity level of the simulation / emulation is related to the established model, and more accurate virtual tests can be used to quantify the fidelity of less accurate models. Thus, timing variability can be managed, and multimodal behavior can be exposed. As software and hardware evolve, new modalities may emerge. The above method can identify when new modalities arise, and the changes 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. Identifying unspecified modalities and bad paths makes it easier to create new hardware because the risk of timing being 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 specific timing events. For example, direct networking to RAM is more efficient with fully quantified timing. Similarly, operating system schedulers can reduce timing variability as the scheduler is tuned, which requires quantification of the potential variability as described above. This 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 timing variability, we can discover how to optimally schedule and insert quiescent points while meeting other system-wide criteria.

[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 begins at S902, and at S910, variation is added to the software. Referring to FIG. 4, variants or nondeterminism 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, thereby increasing safety even if the statistical likelihood of the modality occurring during production or after the software is deployed is low. Dynamic application of randomness by intentionally inserting nondeterminism is used to attempt to disrupt the software to identify the issue. Referring 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 the modality. Referring to FIG. 7, other randomization techniques include oversized allocations (allocations beyond what is required), code allocation, use of different instructions, and the like.

[0082] At S914, the distribution of unspecified modalities associated with the software is identified. Referring to FIG. 7, removing unspecified modalities, e.g., modalities outside the design timing constraints, addresses true safety planning and mitigation issues even as the system becomes increasingly complex. Referring to FIGS. 8a-8b, adding these sources of nondeterminism quantifies modal behavior and determines timing ranges for various executions. This quantification enables discovery of differing software / hardware pieces and ensures they are all within the system's operational design domain. Referring to FIG. 6, critical paths can be identified, prioritized, and execution of other task orders shifted and modified. Task reordering can be statically changed once or dynamically modified.

[0083] At S918, at least a portion of the software is modified to remove unspecified modalities. Referring to FIG. 6, 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 no problems arise. The introduction of nondeterminism not only prevents over-engineering of hardware, but also prevents over-fitting of current software to current hardware. Referring to FIG. 7, the distribution plot informs software developers when time should be spent optimizing execution, reducing variability, etc., so that mode 3 can be shifted left so that variability is not too close to the 100 millisecond 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 adding 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. Execution of the instructions 1006 by the processor 1002 (at least in part) represents an application that implements at least a portion of the methodologies 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 on the non-transitory computer-readable storage medium 1004 to enable the processing circuit 1000 to perform at least portions of processes and / or methods. 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 suitable processing unit.

[0089] The processing circuit 1000 includes an I / O interface 1010. The I / O interface 1010 is connected to external circuitry. In one or more embodiments, the I / O interface 1010 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor direction keys that 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 instructions 1006 (in compressed or uncompressed form) that can be used to program a computer, processor (or other electronic device) to perform the processes or methods 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 any other type of physical medium suitable for storing electronic instructions. In one or more embodiments using optical disks, the one or more non-transitory computer-readable storage media 1004 include 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 on one or more non-transitory computer-readable storage media 1004 to load, execute, and operate 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 the instructions 1006 stored on the 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 the software's design timing constraints 1036. The processor 1002 determines timing bounds 1038 for task execution and determines events within the 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 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 software's execution 1044 of tasks. The display 1070 provides a user interface (UI) 1072 that presents the software, modality distributions, 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] Furthermore, 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. A method for providing timing independence to software, executed by a processor, comprising: Adding variability to the software; running the software with the added variation to identify a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; Including, The method, wherein the identifying the distribution of the unspecified modalities associated with the software includes identifying the distribution of modalities that are outside design timing constraints of the software.

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

3. 2. The method of claim 1, 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.

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

5. 10. The method of claim 1, wherein the modifying the at least part of the software to remove the unspecified modality comprises modifying the at least part of the software to prevent over-engineering of implemented hardware and over-fitting of software to the implemented hardware.

6. The method of claim 1 , wherein the modifying the at least part of the software to remove the unspecified modality comprises optimizing the software's execution of a task.

7. 1. An apparatus for providing timing independence to software, comprising: a memory storing computer readable instructions; a processor connected to the memory; wherein the processor executes the computer-readable instructions to Adding variability to the software; running the software with the added variation to identify a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; configured to perform the operation of 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.

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

9. 8. The apparatus of claim 7, 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.

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

11. 8. The apparatus of claim 7, 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 software to the implemented hardware.

12. 8. The apparatus of claim 7, wherein the processor is further configured to modify the at least a portion of the software to remove the unspecified modality by optimizing execution of a task of the software.

13. A non-transitory computer-readable medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor, Adding variability to the software; running the software with the added variation to identify a distribution of unspecified modalities associated with the software; modifying at least a portion of the software to remove the unspecified modality; causing the processor to perform operations including: A non-transitory computer-readable medium, wherein the identifying the distribution of the unspecified modalities associated with the software includes identifying the distribution of modalities that are outside design timing constraints of the software.

14. The adding of the variation to the software comprises: adding non-determinism to the software to change the timing of the execution of tasks by the software; or 14. The non-transitory computer-readable medium of claim 13, wherein the method further comprises at least one of adding randomization to the software, the adding randomization to the software comprising at least one of adding randomization to memory allocation, oversizing memory allocation, or replacing instructions of the software with different equivalent instructions.

15. The identification of the distribution of the unspecified modality may include: Quantifying 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 within a critical path and rearranging the order of execution of non-dependent tasks that are not within the critical path; 14. The non-transitory computer-readable medium of claim 13, comprising at least one of:

16. 14. The non-transitory computer-readable medium of claim 13, wherein the modifying the at least part of the software to remove the unspecified modality comprises modifying the at least part of the software to prevent over-engineering of implemented hardware and over-fitting of software to the implemented hardware.

17. The non-transitory computer-readable medium of claim 13 , wherein the modifying the at least part of the software to remove the unspecified modality comprises optimizing the execution of a task of the software.

Images