US20170039125A1

US20170039125A1 - System of implementing deterministic real-time, distributed and synchronized for control applications, test and measurement

Info

Publication number: US20170039125A1
Application number: US15/198,147
Authority: US
Inventors: Nestor Hugo Oliverio; Marc Almendros Parra
Original assignee: Keysight Technologies Singapore Holdings Pte Ltd
Current assignee: Keysight Technologies Singapore Sales Pte Ltd
Priority date: 2015-08-03
Filing date: 2016-06-30
Publication date: 2017-02-09
Also published as: ES2552739B1; ES2552739A1; US11106565B2; US20190266027A1

Abstract

System deterministic execution time, distributed and synchronized control applications, test and measurement. System synchronized distributed deterministic execution time for modules (M0, . . . , Mn) control, test and measurement that share at least one trigger signal and a clock signal and comprising a deterministic processor time, using the clock signal and one or more of the trigger signals shared by all modules (M0, . . . , Mn) to run a program distributed modules (MO, . . . , Mn) with precise control the moment of execution of each instruction and synchronize the execution of all or part of the set of modules (M0, . . . , Mn). The time deterministic processor communicates with a common signal bus to all (M0, . . . , Mn) modules, comprising a control bus which share the clock and trigger signals. Optionally, the signal bus includes a communication bus with which the time deterministic processor and the (M0, . . . , Mn) communicates modules together and optionally with a processor or external computer.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. §119(e) from Spanish Patent Application No. 201531155 filed on Aug. 3, 2015 naming Nestor Hugo Oliverio, et al. as inventors. The entire disclosure of Spanish Patent Application No. 201531155 is specifically incorporated herein by reference.

BACKGROUND

The requirements of control systems, test and measurement have grown enormously in complexity in recent years, requiring increasing number of inputs I outputs, and increased capacity and processing speed and synchronization.
In control systems, test and measurement running multiple simultaneous and I or actions very precise timing is very important.
Synchronously management and real-time action and multiple input I output control system, test or measure, is a challenge that has many disadvantages.
And these problems grow significantly in complexity with increasing the number of channels and speed systems.
To attack this problem, test systems and current measurement using different architectures, as explained below.
Some systems are implemented with a centralized master controller that monitors and controls all actions.
This controller performs the calculations and actions triggered measurement and control over the input and output peripherals, sensors and actuators.
The main controller can be, among other examples, a computer, a microcontroller or field programmable gate array (FPGA), according to the requirements of robustness, real-time and speed. Being a centralized controller, all tasks must be performed and synchronized from a single device, which significantly limits the speed and capabilities of the system. This limitation increases significantly with the number of inputs and outputs of the system and the complexity of the tasks to be performed. All this results in performance (‘performance’) and a precision in limited time. Also scalability as required is also very restricted, so generally centralized processing systems require custom designed for each application.
The current trend is therefore the use modular architectures in control systems, test and measurement. Thus maximum flexibility is achieved in terms of scalability, possibility of using standard products from different vendors, ease of repair and renovation, etc. Some of these systems, the most modern, also incorporate the latest technologies in digital processing, such as FPGA and embedded processors that allow for a large processing capacity in each module. The major drawback of these systems is the ability to precisely synchronize all actions of the different modules and calculations in a distributed manner to implement the complete solution of test, measurement and control.
In general to solve synchronization a network of trigger signals (‘trigger’) between the different modules, depending on the capabilities of each module, looking to shoot sequentially, synchronously and accurately is used, the various actions measurement, test and control.
In many cases the propagation time of these signals has a major drawback limiting system accuracy and also the complexity grows significantly with the number of modules involved.
The implementation of these systems with shooting techniques (triggers) is usually very complex and requires a lot of development work and commissioning.
Furthermore, as the number of trigger signals is limited, the possibilities and flexibility are too.
On some platforms, such as PXI Express, the system provides a special module include centralized generating trigger signals that can trigger actions in other modules.
This approach solves some problems propagation of triggers and improve accuracy, but still has major limitations when synchronizing multiple modules with requirements of cross shot signals.
In addition, the centralized approach does not allow shooting or too poor to integrate actions trigger the results of measurements and calculations distributed over several modules.
The objective technical problem that arises is therefore to provide means for the multi-module synchronized and deterministic processing in real time to time of the plurality of inputs I outputs of any control system, test and measurement.

SUMMARY

The present teachings serve to solve the above problem, solving the drawbacks of the solutions discussed in the prior art by providing a system of deterministic distributed run-time control applications, test and measurement, which allows you to run hardware sequences and programs with full timing accuracy and synchronization between all modules that make up the system.
The present teachings relate generally to electronics and, in particular, to the industrial area of programmable systems to perform control functions, test and I or measurement.
More particularly, the present teachings relate to a system for deterministic execution time (ie, precisely controlling the execution time of each action, totally repeatable and some randomness), distributed and synchronized control applications, test or measure, allowing multiple control instruments, test and measurement can perform a task running each of the shares with full time synchronization.
The present teachings are based on a deterministic processor time using a time deterministic processor (TDP) in time, which can be part of any computer hardware control module, test and measurement. According to various representative embodiments, the processor may be implemented TDP on a microprocessor, an FPGA or an application specific integrated circuit (ASIC) device), FPGA or ASIC being the most convenient platform for giving higher performance. The Deterministic Processor in Time (TDP) allows executing instructions by hardware indicating with absolute precision execution time of each instruction and all modules of the control system, test and measurement, regardless of their function, for example, the generation modules all signal scanning, communications, digital inputs and outputs, etc., can incorporate adaptations same time deterministic processor, TDP. This TDP enables distributed synchronized global actions to be processed and executed. These distributed synchronized global actions include, but are not limited to conditional jumps synchronized in all modules of the system according to the calculations, measurements or information from any of the modules.
The spread of the decisions and implementation of global actions are performed with full synchronization in all modules and automatically and transparently to the user.
One aspect of the present teachings relate to a system of distributed execution comprising a set of two or more modules to execute control applications, test and measurement, sharing at least one trigger signal and a clock signal, wherein all modules that together they comprise a deterministic processor time (TDP) using the common clock signal and at least one of the trigger signals shared by the modules to synchronize the execution of at least part of the set of modules (or full set).
In accordance with various representative embodiments, a single module may be implemented, in which case the synchronization capabilities would be used, but all other features and advantages of deterministic execution time would not be used.
In the system of distributed execution proposed accuracy runtimes and synchronization between modules it depends exclusively on the bias or skew and fluctuations (i.e., jitter) of the common clock signal to all modules and in particular the time deterministic processor comprises calibration capabilities to cancel the clock skew between modules.
Some of the technical advantages of the various embodiments against the solutions of prior art are:
The present teachings allow the user to program the hardware of different modules using an intuitive graphical environment for code generation text or command files (sometimes referred to as “scripting”).
Global synchronized actions, such as synchronized global jumps are programmed extremely easily as if all the modules were a single device and the outside centralized execution.
At any time you can control with precision temporary total actions implemented in any of the modules.
The programming of the modules can be done by programming software that incorporates features check timing (‘timing’) and validation of real-time synchronization while programming, which allow you to work with multiple modules simultaneously and very simple.
The teachings have all the advantages of modular architectures and provides a fully scalable mechanism distributed and synchronized implementation that provides absolute timing accuracy and is very simple to use and implement regardless of the number of modules in the system.
The teachings achieve a processing speed and unique synchronization, requiring only a single clock signal and a single trigger signal (trigger) multi-point, both common to all modules, regardless of the number of modules in the system.
This significantly simplifies the requirements of interconnections between the modules with respect to current systems generally require many triggers, and to specific modules whose only function is to generate the triggers to synchronize the other modules.
In accordance with a representative embodiment, the bias or skew synchronization between modules depends only on the bias signal clock (sometime referred to as “clock skew”) common to all modules, which is usually very low, and is independent of bias trigger signals, which usually has much higher values and the clock is very difficult to reduce in case of multi-point triggers.
The present teachings also contemplate the possibility of using multithreading Deterministic time in the same module that, by interlacing technique instruction by instruction, ensure accuracy of time, which in conventional processors is impossible.
The system also provides tools to debug the software that significantly simplify the implementation of control systems, test and measurement multi-module. For example, it has the possibility of introducing breakpoints that stop global execution in a moment of time in all system modules synchronously.
In accordance with the present teachings, modules with TDP can coexist, and modules that do not include the technology described herein, because it of special instructions for generating and wait for trigger signals (triggers) in accordance with certain embodiments, can interact with these other modules, like with external events.

BRIEF DESCRIPTION OF THE DRAWINGS

It then goes on to describe very briefly a series of drawings that help to better understand the present teachings and which are expressly related to certain representative embodiments presented as a non-limiting example thereof.

FIG. 1 shows a block diagram of the system architecture of distributed processing control modules, test and measurement, according to a representative embodiment.

FIG. 2 shows a block diagram of the architecture of a system module with distributed processing Time Deterministic processor, according to a representative embodiment.

FIG. 3 shows a block diagram of the architecture of the processor in Time Deterministic system, according to a representative embodiment.

FIG. 4 shows a diagram of the structure of the instructions used by the processor in Time Deterministic system, according to a representative embodiment.

FIG. 5 shows a diagram of the programming process, compilation and execution of instructions in the hardware of the system modules, according to a representative embodiment.

FIG. 6a —shows a graphical interface software programming tool multi-module synchronized to the system, with multiple windows flowchart of various system modules, according to a representative embodiment.

FIGS. 6B, 6C and 6D—show a flowchart window respectively for each module, the multi-module of FIG. 6A graphical programming tool, according to a representative embodiment.

REPRESENTATIVE EMBODIMENTS

Then possible embodiments of the distributed execution system proposed for control systems, test and measurement are described.
FIG. 1 shows a schematic diagram of the modular block architecture of the system for distributed execution control applications, test and measurement. The system comprises multiple modules (M0, . . . , Mn) which, in turn, comprises a plurality of inputs I outputs (IO0, . . . , IO”) or port 1 I O. The (M0, . . . , Mn) system modules perform control functions, test and measurement. Each module (M0, . . . , Mn) connected to a common bus signals (120) to all modules (M0, . . . , Mn), comprising a control bus (120 a) through which all the (M0, . . . , Mn) modules share one or more clock signals and one or more signals trigger or triggers. Furthermore the signal bus (120) may include one or more communication buses (120 b) through which each module (M0, . . . , Mn) communicates with the rest and, optionally, with an external processor (130), which can be a PC, an embedded controller, etc. In addition, each (M0, . . . , Mn) module can have one or more ports programming and debugging programming (110). Each and every one of the (M0, . . . , Mn) as core modules have a TDP processor or processor in Time Deterministic (100). The TDP is connected to the signal bus (120) and the rest of the TDP also independent module. FIG. 2 more particularly shows the block diagram of the internal architecture of one of those (M0, . . . , Mn) system modules of FIG. 1.
The module (Mi), i=0, . . . , n, is implemented in a device whose components or hardware assembly (200) comprises in the core in the Time Deterministic Processor (100) which, in turn, can be implemented in a device (201) processing: FPGA, microprocessor, ASIC, etc.
The device (201) communicates through the input I output (LOI) and the signal bus (120), with at least one clock signal and at least one signal common shooting for all modules (M0, . . . , Mn) system, requiring at least one trigger or trigger signal to perform synchronization between modules.
FIG. 3 shows a block diagram of the architecture of Deterministic Processor in Time (100) is implemented with a core or common core (300) to all modules, ensuring the proper functioning of synchronization regardless of the type of instrument control, test and measurement, which is incorporated, and one or more specific blocks (P0, . . . , Pn) for implementing additional functions including the various specific functions that characterize each type of test and measurement module.
This architecture allows to easily incorporate new instructions to meet new requirements.
The core (300) of the TDP (100) processor communicates with other components (301): hardware, data memory, input I output, etc., the module and the common signal bus (120) all modules.
In addition, the core (300) of Deterministic Processor in Time (100) reads, from a memory (302) of program instruction words (303) used during program execution on the hardware. The core (300) TDP (100) processes the instruction words (303) at the right time, executes the instructions for the core and also sends instructions about executioners (P0, . . . , Pn), which interpret and execute further instructions. Each engine launcher can run one or more types of instructions (303) and may be one or more executioners of instructions (P0, . . . , Pn). Notably, the number and type of instructions executed depends on each specific instrument.
FIG. 4 shows the structure of instructions handles in Time Deterministic Processor (100). The instruction word TDP processor (100) has a special structure to include at least one field (DW [1], DW [2]) the exact time of execution of each instruction word, which can be absolute time, or on the previous instruction. It also contains a control field (DW [0 j) that allows enabling the execution of one or more instructions that can be placed flexibly in the instruction word. The instruction word has a variable length depending on the needs of the module in question, the larger the word instructions can be executed simultaneously in each module which is a very important control systems, test and measurement advantage.
The TDP (100) processor has special instructions synchronized timing and conditional jumps, which allow a decision to spread all modules (M0, . . . , Mn) system and all running a conditional jump or other action under this decision with complete time synchronization. This is a unique feature of TDP (100). To achieve this full synchronization TDP (100) requires a single clock signal and a single trigger signal or trigger, both common signals to all modules (M0, . . . , Mn). A trigger signal is a multi-point digital connection that connects all (M0, . . . , Mn) modules together to form what is known as a “wired OR” or a “wired AND” according to the standard-drivers logical interface. If the system has with more than one of these trigger signals, such as the PXI Express platform has eight trigger signals, the TDP (100) can optionally make use of the additional trigger to increase the synchronization speed and repetition decisions and synchronized actions.
Furthermore the TDP (100) processor can be integrated into the transfer Decisions communication buses (120 b) available modules (M0 . . . Mn). By Interconnection: example, if a control platform, test and measurement PXI or PXI Express, the communication bus (120 b) used by the deterministic processor time (100) is respectively a Peripheral Component Interconnect (PCI) bus, components or PCI Express bus.
For example, a representative embodiment is implemented on PXI or PXI Express platform are a reference standard in control applications, test and measurement in most industries.
A PXI Express chassis has a printed circuit board backplane, which distributes across all modules the following signals: supply, a PCI Express bus, a clock of 100 MHz, CLK100, 10 MHz clock, CLK10, a signal sync referred to 100 MHz clock and provides a reference pulse to 10 MHz, SYNC100, and 8 trigger signals multi-point PXI trigger Bus, connecting all modules in a “wired aND” with logical drivers like “open collector”, among others.
The modules have an FPGA that communicates with a PC and with the specific hardware that makes up each specific type of instrument control, test and measurement.
For communication between the PC and FPGA, PCI Express is used. By way of example, a known switch I controller, such as switch I driver devices can be used. Alternatively, the connection can be made directly to the FPGA. The FPGA controls the PCI Express communication and other hardware components.
Within the FPGA is implemented the TDP (100) that works with 100 MHz clock, CLK100, to control with precision the time of execution of each instruction and uses the bus 8 PXI triggers and the reference signal SYNC100, to achieve a perfect synchronized execution across all modules.
Bias or skew in synchronization between modules depends only on 100 MHz clock skew in different slots in the chassis and is independent of bias trigger signals and reference SYNC100.
Clock skew depends only on the chassis used and is guaranteed to be less than 250 ps, although according to the chassis can be much lower and it can be significantly improved if an initial calibration is performed. The user can select which of the 8 shot available on the PXI Express wants to allow to use the TDP (100) and the software manages the resources allocated. For PXI has not CLK100 and SYNC100 the signals, so that the embodiment is implemented using the 10 MHz clock, CLK10, and eight multi-trigger signals point. PXI bus communication is used instead of PCI PCI Express.
Another representative embodiment is implemented on an LXI platform, LAN Extension for Instrumentation: Extension of Local Area Network Instrumentation—where the clock signal and trigger bus (120 a) communicate between modules—a wired trigger bus can be provided in the LXI specification and where the communication bus (120 b) consists of a Local Area Network (LAN).
Another representative embodiment is implemented on the Advanced Telecomunications Architecture (MicroTCA platform), micro computing architecture advanced-telecommunications or some of its variants, as microTCA.4, where the clock signal is communicated between modules using some of the various ports covered by the standard clock, CLK1, CLK2, CLK3, TCLKC or TCLKD, and trigger signals can communicate through ports 17 to 20. Where the communication bus (120 b) can be selected between Ethernet, PCI Express and SRIO, Rapid Serial Input Output: Inputs Outputs in Series Fast, depending on the implementation of the system.
Another representative embodiment is implemented on the platform AdvancedTCA Extensions (AXIe) for instrumented: Extension for AdvancedTCA Instrumentation—where, similar to PXI Express, CLK100 backplane signals and SYNC are used, and one or more of the trigger signals 12 MLVDS available and where the communication bus (120 b) can be selected from a LAN connection or PCI Express.
The decision on which global action or conditional jump is executed and timing may depend on one or more modules (M0, . . . , Mn) system.
To force synchronization (M0, . . . , Mn) modules, unconditional include a synchronization point, the same mechanism as in synchronized conditional jumps considering the jump condition is always false is used.
In addition, the TDP (100) has special synchronized execution instructions as the “Start” node that allows you to start running in all modules (M0, . . . , Mn) simultaneously.
The synchronized actions, synchronized diving and synchronization points can involve all (M0, . . . , Mn) system modules or only a subset of them.
The TDP (100) also has flow control instructions as while, if, for etc, both local and multi-module synchronized.
It also has math, logic operations, and access to data and variables of the module itself or the rest of the modules.
And it has all the necessary instructions to control the specific capabilities of the module (Mi), i=0, . . . , n, on which it is implemented.
The TDP (100) also has instructions awaiting triggers generation and to interact with modules not incorporating a TDP (100) and with external events.
There are two basic types of instructions that can run the TDP (100):
The instructions to shoot and do not consume time TDP (100), ie these instructions execution starts and in the next clock cycle TDP (100) can process a new instruction word and execute further instructions.
These instructions may require several cycles to run and run in parallel regardless of operation of TDP (100).
How time consuming TDP (100), so until it completes execution TDP (100) can not process the next instruction word and execute the following instructions; Typical examples are the control instructions waiting, wait, or flow: while, for, if, etc.
Time consuming instructions are implemented in the core (300) of the TDP (100), while those not, can be implemented in both the core (300) and the instructions executers (P0, . . . , Pn). In the case of the instructions that trigger, you may be able to start multiple runs sequentially when the previous run is still ongoing and they are implemented using filters based on pipeline architecture.
The TDP (100) also has a deterministic time system threads or threads, which allows to include in each module (Mi) more than one thread that runs in parallel with an interlacing technique instruction by instruction. This technique ensures a deterministic distribution of instruction execution in all threads, ensuring accuracy of time. The main thread running natively synchronized with other modules and semaphores and events that allow you to synchronize the different threads of the same module to each other are included. Furthermore Choose whether you want to include any of the global instructions synchronized in one or more of the secondary threads.
FIG. 5 shows schematically the process of programming, implementation and compilation instructions TDP (100) of each (M0, . . . , Mn) module. The user program the entire system or part of it, implementing a code for each of the modules (M0, Mn) involved in the application control, test and measurement.
To implement the code it has local and global instructions to all modules (M0, Mn), as described above.
For the first phase of the process of entering the code (500), you can use tools file generation orders (501) or scripts or programming platforms based on text (502) or graphics (503) Instructions global run on all modules in a group or in a subset and TDP (100) guarantees its fully synchronized execution.
Not all (M0, . . . , Mn) system modules must work together, it is possible to have groups of modules that work together, which are programmed and operated completely independently synchronized between modules outside the group.
The group is programmed with the ability to execute instructions in all of them in sync as if they were a single hardware and can also include specific local instructions for each module.
The source code written by the user can be graphic or text and provides graphic or script generation tools, as discussed above, that let you easily add multi-module synchronized instructions and specific to each local module.
The programming tool performs all checks for consistency of global and individual code and then compiles (510) the source code (511) of the group as a whole to obtain a compiled code (513), from which will generating a code execution (CM0, . . . , CMN) specific to each module (M0 . . . Mn). In the Compilation (510) instructions for high-level user instructions can run the TDP (100), whose compiler (512) manages resources trigger and communication available to achieve automatically and transparently to the user synchronization become and sharing of decisions between (M0, . . . , Mn) modules.
The compiler (512) verifies the correct syntax for all instructions and that resources needed at all times for execution. In summary, the entered code (500) by the user compiled to generate the specific executable code (CM0, . . . , CMN) for each module (M0 . . . Mn) and, during compilation, the compiler (512) TDP (100) generates the need for synchronization of each of the global synchronization instructions analyzing each section code. The programming tool and compilation usually runs on a computer, but could run on any other platform, and also the programming and compilation tool could run on different platforms. The executable code (CM0 . . . CMN) generated for each module are downloaded to all group modules and then the code is executed by the TDP (100) synchronously in the hardware of each system module (530). Downloading executable code (CM0, . . . , CMN) each (M0 module . . . Mn) and control running and debugging (520), using graphical tools (521), command (522) and I or library (523), can be made by the same communication bus (120 b) connecting all modules (M0, . . . , Mn) between themselves and with the PC or system controller if available, or through a port specific programming available in each module.
For programming the hardware system (530) it is counted with a graphic software, as shown in FIG. 6A which allows easily programmed each module by one or more flowcharts, as shown in detail by way of example in FIG. 6B-6D.
The software allows you to select which group of modules you want to work in sync and create a project. Once the project is created has a flow diagram window per module, a window of further flow diagram for each thread and additional editing windows and configuration instructions, debugging, etc. For example, in FIG. 6A a properties window (640), where some general parameters for scheduling the execution of the selected element at all times and special instructions of the element are configured, along with three windows diagram shown flow: A flow diagram window (600) to a first module, shown in detail as an example in FIG. 6B; another window (601) for a second module, shown in detail as an example in FIG. 6C; and a third (602) to a third module, as shown in detail in FIG. 6D example. The software allows you to program all modules simultaneously and automatically manages the global synchronized items.
In addition, the software allows you to save the project and then loaded with the same graphic software, user libraries or other code editing environment.
User libraries let you load projects already created, modify, compile, load them into the hardware and control its execution completely.
Thus, the hardware implementation code can be integrated into any user application.
Since libraries user can, start, pause, stop the execution, as well as exchange data and events between the PC and modules.
You can have a collection or library of hardware programs that use the same or different modules and run them at different times of the execution of software.
In addition, the software allows to download the program for each module group, run and debug the program, inspecting variables, state of TDP (100) and insert breakpoints or breakpoints, local and global.
Local break points only stop the execution of a module, while global stop to all modules in the group.
Global break points are very important in synchronized multi-module tool systems.
These are introduced into one of the modules and replicate the end of the section synchronized in other modules of the group.
The user can move freely break global points within each section to adjust the exact stopping point of each module.
The flowchart of each module is composed of instruction boxes and arrows of time as shown in FIGS. 6A-6D. The arrows interconnecting a source element with a destination element and the flowchart correspond to a given instant of execution of the target element relative to the source element. Beat arrows indicate the exact time specified in nanoseconds (ns) in the 6B-6D, in which the execution of the next instruction will start from the previous. Instruction boxes may contain actions, calculations, flow control instructions, data transfer, etc. The instructions can be local to the module or multi-module global synchronized. The synchronized elements (610, 611, 612, 613) are inserted into one of the modules and are automatically replicated in the other modules in the group. The software generates the need to maintain synchronization and propagate decisions transparent to the user to ensure the implementation of all the boxes synchronized at the same instant of time code.
Boxes or local elements (620, 621, 622, 623, 624, 625, 626, 627, 628) of each module can maintain synchronism or not.
There are cases in which local elements (620, 621, 622, 623, 624, 625, 626, 627, 628) of all modules (M0, . . . , Mn) corresponding to words of instruction (303) local, when running not maintain synchronism between the modules because the instruction word (303) Local consumes not known by the compiler (512) prior to execution time. In this case synchronization between all modules is recovered in the following global element synchronized to the local instruction word (303) causing desynchronization.
Boxes or local control structures that maintain synchronism are those that trigger actions and not time-consuming or time consuming but it is known at compile time before execution. Boxes or local control structures of sync are those whose runtime can not be known at compile time, for example a While command (621) with a variable, or Wait command of an external event. The software ensures synchronized execution of the boxes corresponding to synchronized elements (610, 611, 612, 613), that allows each section between synchronized global elements can be analyzed separately. If all local boxes on a stretch maintain synchronism, the software can determine with precision the execution time of each local instruction with respect to the synchronized starting node of the section and thus automatically adjust the time of the last arrow before the box synchronization end of the stage and achieve so all modules execute the synchronized element 5 final stretch at the same time. If any of the local branches of synch, the software may not accurately determine the time of the boxes from the point of sync, but the synchronism between all modules in the synchronized box end of the section in question will recover: this is done with an additional procedure and is indicated by the dotted line at the end of the section (630). For example, in FIG. 6A, in the properties window (640), the 10 property “Time” of the selected local box (624) indicates that the box will run as minimum 140 ns after the synchronization point immediately above, but may take longer to run indefinitely depending on how many local instruction cycles While (621) running before the selected box (624) is repeated.
The software manages multi-module synchronization transparently to the user while programming is done thus synchronized boxes are displayed aligned with all modules and times are adjusted in real time. This makes the multi-module programming is very simple, as if a single device be scheduled.
In view of this description and figures, those skilled in the art will understand that the invention has been described according to some preferred embodiments thereof, but multiple variations can be introduced in said preferred embodiments or applied to different standard or custom platforms without leaving the scope of the invention as has been claimed.

Claims

We claim:

1. A system in timed deterministic execution time for distributed control applications, test and measurement, comprising a set of at least one module (M0, . . . , Mn) to execute control applications, test and measurement, wherein all the (M0, . . . , Mn) the set modules share at least one trigger signal and a clock signal, and comprise a deterministic time processor, and the time deterministic processor uses the signal clock and one or more of the trigger signals shared by all modules (M0, . . . , Mn) to run a program distributed modules (M0, . . . , Mn) controlling every moment of execution of each instruction program and, if the assembly comprises more than one (M0, . . . , Mn) module to synchronize the execution of all or part of the set of modules (M0, . . . , Mn).

2. The runtime system distributed according to claim 1, wherein the deterministic time processor communicates with a common signal bus to all modules (M0, . . . , Mn), comprising a control bus carrying the clock signal and at least one trigger signal, shared by all (M0, . . . , Mn) modules.

3. The system distributed execution according to claim 2, wherein the deterministic processor time communicates with a communication bus incorporated in the signal bus and through the modules (M0, . . . , Mn) communicate with each other.

4. The runtime system distributed according to claim 3, wherein the (M0, . . . , Mn) modules communicate with an external processor via the communication bus.

5. The distributed execution system, according to claim 4, wherein the deterministic time processor have a common core to all modules (M0, . . . , Mn) and the core deterministic processor time reads instructions of a memory, runs on a given instant of execution instructions, which are selected from global instructions synchronized to all or part of the modules (M0, . . . , Mn) and local to each module, and passes instructions to at least one instruction executer (P0, . . . , Pn) to perform additional functions, which are selected from common functions all (M0, . . . , Mn) modules and functions as an application specific control, test and measurement of each module (M0, . . . , Mn).

6. The system of distributed execution, according to claim 5, wherein the deterministic processor time executes an instruction word comprising at least one field (DW [1], DW [2]) indicating an exact time of execution of each instruction word.

7. The system of distributed execution, according to claim 6, wherein the deterministic processor time executes an instruction word comprising a control field (DW [0]) that enables execution an instruction or multiple instructions simultaneously.

8. The system of distributed execution, according to claim 7, wherein the deterministic processor time executes synchronized global instructions, synchronization and synchronized conditional jumps, spreading a decision to all or part of the modules (M0 . . . , Mn) which, according to the decision, perform an action or a conditional jump with time synchronization.

9. The system of distributed execution, according to claim 8, wherein the decision propagated by the deterministic processor time between all modules (M0, Mn) of the assembly and on which the conditional jump or action is executed synchronized all depends on one or part of a set of modules (M0, . . . , Mn).

10. The system of distributed execution, according to claim 9, wherein the deterministic processor time executes instructions to generate and waiting at least a trigger signal to interact with external events and other system modules which do not incorporate a deterministic time processor.

11. The distributed execution system, according to claim 10, wherein the deterministic time processor uses threads to include in each module (M0, . . . Mn) of the set more than one thread that runs in parallel with an interlacing technique instruction by instruction.

12. The system of distributed execution, according to claim 11, wherein the deterministic processor time comprises a compiler that converts a source code with high-level instructions, introduced by a user for all (M0, . . . , Mn) the set modules as a single programmable device, in a compiled code from an executable code (CM0 is obtained, . . . CMN) specific for each (M0, module . . . Mn) with words of instruction containing synchronized local and global instructions executable by the deterministic processor time, where the compiled code takes into account the exact time of execution of each instruction word for synchronization of all instruction words global for all specific (M0, . . . , Mn) of the set in the execution of the executable code (CM0, . . . , CMN) modules each module (M0, . . . , Mn).

13. The distributed execution system, according to claim 12, characterized by comprising a graphical user interface through which the user enters instructions for programming high level each module (M0, . . . , Mn) of set by at least a flow chart comprising at least one synchronous element entered by the user in one of the assembly modules and the at least one synchronized element is automatically replicated in other modules set to be executed as an instruction word overall in a moment of time for time deterministic processor of each module.

14. The system of distributed execution, according to claim 13, wherein the graphical user interface further comprises arrows interconnecting an origin element with a destination in the flow chart element and corresponding to a given instant of execution element destination regarding the source element.

15. The distributed execution system, according to claim 13, wherein the graphical user interface further comprises local elements to each module (M0, . . . Mn) of the set corresponding to words of instruction (303 local), the execution maintains synchronism with the instruction words Global only if the local instruction words do not consume time or if they consume a time known by the compiler prior to execution.

16. The distributed execution system, according to claim 13, wherein the user interface comprises global rupture points all or part of the modules (MO . . . Mn), which correspond to instruction words special time deterministic processor and stop execution time deterministic processor at a particular point within the segment synchronized in all or part of the set of modules (M0, . . . , Mn).

17. The distributed execution system, according to claim 16, wherein is implemented on a platform control and test As is selected from PXI and PXI Express.

18. The distributed execution system, according to claim 17, wherein is implemented on a platform LXI.

19. The distributed execution system according to claim 18, wherein is implemented on a platform control, test and measurement selected from MicroTCA microTCA.4, AXIe or an evolution of AdvancedTCA.

20. The distributed execution system according to claim 19, wherein the deterministic time processor is implemented in a device processing device selected from microprocessor, FPGA or ASIC.