Patent Description:
A runtime system refers to the collection of software, firmware, and/or hardware resources that enable a software program to be executed on the operating system of a computer. The runtime system is a composite mechanism designed to provide program execution services, regardless of the programming language being used. Runtime is defined as a lifetime phase of software or firmware program development, beginning when the program is loaded to memory along with its framework, components and libraries. A compiler loads the program to memory and the operating system assigns required memory, processor resources, input/output resources to the program from start to finish of the runtime.

Today, software/firmware for a runtime system used in automation systems (e.g., an industrial system of robots deployed in a production or manufacturing line) are monolithic and built for a specific purpose. All functions configured by a software developer for a runtime system are hardcoded and any modifications are nearly impossible, forcing a rewrite the entire runtime program. For example, if it is desired to add a new driver to a deployed runtime system, such as a new driver to support Bluetooth or a new network driver, the drivers are in kernel space and monolithic, preventing a simple reconfiguration of the runtime system. As another example, if the runtime system is configured to be real-time operable, it cannot later be easily modified to be non-real time operable. Or if the runtime system is originally designed to have preemptive scheduling, and later it is desired to try other kinds of scheduling, this change to the program is not practically possible. The implementation of new features requires very large engineering efforts. Adapting automation runtime systems to new requirements in a very short time is a challenge in current implementations.

Current approaches for runtime system development include Brownfield development and Greenfield development. In Brownfield development, an existing runtime system is modified or adapted to the new requirements. If the new requirements can be easily addressed by the existing functionality, this requires simple configuration. However, most times the new requirements require significant re-engineering of the runtime system and this causes long development cycles that take from months to years. Furthermore, these modifications to the original runtime system often introduce errors that are costly to fix. One example of this is the use of programmable logic controllers (PLCs) to control water control systems in Navy ships. The PLC runtime system must be hardened to the specific requirements of maritime environments. This results in separate system development branches and introduces software engineering overheads.

In Greenfield development, runtime systems are developed from scratch as a brand new runtime system. This allows the runtime system developer to create a custom solution to exactly address the new requirements. However, starting a brand new runtime program from scratch takes a major effort that can span over multiple years. Furthermore, once the runtime system is released and new requirements arise, the "brand new" runtime system must be adapted and re-engineered. Developing a brand new runtime system is extremely expensive, and this yields significant organizational overheads as separate company divisions and groups must be maintained for the isolated developments. Neither the Brownfield nor the Greenfield development approach allows for easy modifications whenever new requirements arise.

Further background art may be found in <CIT> disclosing a method of implementing a software system on a target-platform. The method includes preparing a specification document including statements that collectively specify requirements of the software system. The requirement statements are expressed with language elements of a specification language, and the specification document has an associated source file.

A system and method are disclosed for adapting an automation runtime system to new requirements in a very short time through a runtime specific language that composes reusable runtime functions into the desired functionality. This adaptation moves away from the common notion that programs of runtime systems must be hardcoded (i.e., data or parameters being directly embedded into the source code instead of obtaining the data or parameters from eternal sources or generating at runtime). Aspects of functionality, such as timing, concurrency, availability, safety, and other properties of the runtime system are composed and defined as a configuration according to the runtime specific language instead of design decisions being encoded in a fixed monolithic format for deployment. In the domain of automation systems, examples of functional configurations include realtime/non-realtime, and field bus protocol support (e.g., OPC-A), which would normally require building a new firmware to be supplied to customer whenever an update is needed (e.g., upon a new protocol being introduced). With the disclosed embodiments, the runtime system can be adapted - new features can be added or features can be updated to the runtime system using configuration modules, such as for stitching, stacking, and specialization operations on the reusable functions. Such runtime system reconfigurations can occur without having to shut down the automation system to deploy an entirely new runtime software or firmware as with current monolithic designs.

In an aspect, a system is provided for constructing a reconfigurable runtime system used in an automation system using reusable runtime functions (RRFs). The system has a memory with modules stored thereon and a processor for performing executable instructions in the modules stored on the memory. The modules include a specialization module configured to execute a specialization operation to configure or customize at least one RRF to satisfy functional requirements of the automation system. A stitching module is configured to execute a stitching operation that connects output of at least one RRF to input of one or more other RRFs. A stacking module is configured to execute a stacking operation that stacks RRFs as layers to create new abstractions, functionality and services. The specialization operation, the stitching operation, and the stacking operation are performed using one or more keywords according to a runtime specification language.

Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like elements throughout the drawings unless otherwise specified.

Methods and systems are disclosed for solving the above technical problem by constructing and adapting use-specific runtime systems using a configuration programming language to instantiate functionality through reusable runtime functions (RRF). The configuration programming language builds functionality, specifying the runtime behavior by turning RRFs on or off as desired. These RRFs are interoperable with one another such that the compatibility among different runtimes is assured. For example, even when an RRF such as "OPC UA Communication" is used in runtime systems for different automation use cases, such as building automation and factory automation, elements of the two runtime systems can be shared seamlessly because they use same reusable functions, despite how it is used or how it is configured. This reusability and interchangeability of runtime functions is the basis for the embodiments of this disclosure, which can greatly accelerate development and adaptation of runtime systems.

TABLE <NUM> below provides a description of these various examples of RRFs that may be instantiated according to the embodiments of this disclosure.

<FIG> shows an example of a system for creating and adapting a runtime system in accordance with embodiments of the present disclosure. A computing device <NUM> includes a processor <NUM> that executes modular algorithmic modules stored in a non-transitory memory <NUM>, including an RRF instantiation module <NUM>, a specialization module <NUM>, a stitching module <NUM>, a stacking module <NUM>, a compiler <NUM>, a deployer <NUM>, and user interface module <NUM>. A user may operate computing device <NUM> through a user interface <NUM>, such as a keyboard, display, touchscreen, or the like. In an embodiment, RRFs are defined and configured by specialization of each RRF, stitching of RRFs, and stacking of RRFs using a configuration-based language. Once the runtime system is developed and compiled, it may be deployed to a host device or system <NUM> via a network connection <NUM>. A storage device or network <NUM> is accessible to the computing device <NUM> via the network <NUM>, which may store an RRF database of data used as a repository of available RRFs, instantiated RRFs, and configuration data generated during creation of the runtime system. The RRF database of available RRFs may be created beforehand by a runtime system provider. A remote artificial intelligence (AI) module <NUM>, accessible via a network <NUM>, interfaces with memory <NUM> and can be trained to generate a model to determine optimized parameters for the RRFs.

For new runtime system development, an RRF instantiation module <NUM> is configured to execute instantiation of each RRF according to a Runtime Specification Language, extracting information about the available RRFs and parameter ranges from the RRF database in storage <NUM>. Selection of RRFs to be instantiated are based on requirements of the automation system. In an embodiment, a runtime system adaptation may be implemented by starting with an existing runtime system as a working template, and one or more additional functionalities can be appended to the adapted runtime system by RRF instantiation module <NUM>.

Specialization module <NUM> is configured to execute a specialization operation to configure or customize each RRF to satisfy functional and non-functional requirements of the automation system. Each RRF is definable with selectable options for functions and subfunctions. For example, a Scheduling RRF may be defined by a user through a user interface by selecting from among functions listed in Table <NUM>, such as (a) soft scheduling, or (b) hard scheduling (e.g., static hard scheduling, dynamic hard scheduling). Subfunction options for hard scheduling can include preemptive, and non-preemptive. More particularly, the runtime system may include a scheduling RRF defined such that resources are allocated using dynamic hard non-preemptive scheduling. In an embodiment, specialization module <NUM> is configured to directly execute instantiation of an RRF for the runtime system in a manner as described above for the RRF instantiation module <NUM>, acting as a substitution.

Stitching module <NUM> is configured to execute a stitching operation between to RRS such that the outputs of one RRF become the inputs of another RRF. For example, in the case where information of a Timing RRF must be communicated to a Scheduling RRF for it to perform its function, stitching module <NUM> stitches the Timing RRF to the Scheduling RRF.

Stacking module <NUM> is configured to execute a stacking operation such that RRFs can be aggregated and layered to create new abstractions, functionality, and services. For example, a Logging RRF can be stacked on top of a Timing RRF configured as hard real-time, or a Scheduling RRF configured as preemptive dynamic scheduler. By stacking of the Logging RRF with other RRFs, the Logging RRF can provide logging capabilities of the data generated by the underlying RRFs. In an embodiment, two or more RRFs are stacked to define or adapt a portion of the runtime system.

Generally, a computer-accessible medium may include any tangible or non-transitory storage media or memory media such as electronic, magnetic, or optical media-e.g., disk or CD/DVD-ROM coupled to computing device <NUM>.

<FIG> shows an example of a runtime system adapted from an existing runtime system in accordance with embodiments of this disclosure. In this example, an existing runtime system Runtime_A is configured with a cloud-based runtime engine <NUM>. A new runtime system Runtime_B, here configured with an edge-based runtime engine <NUM>, can be adapted from runtime system Runtime_A using runtime info sharing <NUM>, and then performing specialization, stitching, and stacking operations to reconfigure the assembly of RRFs according to the new requirements of the runtime system data flow. As shown, specialization operation <NUM> for Logging RRF <NUM> is customized to specifications for runtime system Runtime_A while Logging RRF <NUM> is customized to unique operational needs of runtime system Runtime_B. Stitching operation <NUM> for various RRFs, such as stitching of Timing RRF <NUM> and Scheduling RRF <NUM> allows timing information output by Timing RRF <NUM> to be input for Scheduling RRF. Stacking operation <NUM> of RRFs, such as stacking of Scheduling RRF <NUM> and Security RRF <NUM>, is utilized for runtime system Runtime_A, whereby scheduling of security data is established. Generally, scheduling of any function can be achieved by stacking the Scheduling RRF <NUM> on top of the respective RRF associated with the particular function to be scheduled. The stacking, stitching and specialization operations executed for adapted runtime system Runtime_B generate a configuration of RRFs that is unique from runtime system Runtime_A.

<FIG> shows an example of a runtime system development and deployment onto a host device as a runtime system in accordance with embodiments of this disclosure. In an embodiment, Runtime Specification Language (RSL) <NUM> is used to instantiate an RRF and to specialize, stitch and stack RRFs for a new or adapted runtime system. A runtime program <NUM> is developed according to RSL <NUM>, with user <NUM> defining specifications of the runtime system using the available RRFs. In an embodiment, user interface <NUM> (<FIG>) is configured to process received instructions to define parameters and variables for the RRFs. For example, a user <NUM> may enter instructions according to the RSL <NUM> on a command line interface (CLI) (e.g., using user interface <NUM> shown in <FIG>). In an embodiment, AI module <NUM> (<FIG>) is trained to learn optimized RRF parameters for requirements of the automation system, and composes elements of the runtime program <NUM> to define specifications of the runtime system. The contribution of the AI module may be to compose parts of the runtime program <NUM>, to be presented to the user at the user interface for assistance in developing the runtime program <NUM>.

The compiler <NUM> compiles the runtime program <NUM> to generate the runtime code. In an embodiment, the runtime system includes an RRF database <NUM> with available RRFs, each RRF having a parameter field with selectable options such as presented in Table <NUM>. Compiler <NUM> uses RRF database <NUM> to map variables of the runtime program <NUM> to the RRFs and the RRF parameters according to the specifications of the runtime program <NUM>, generating a compiled runtime code that can be used by the RSL deployer <NUM>.

Deployer <NUM> deploys the compiled runtime code onto a host system <NUM> to enable runtime operation by the host's operating system. Deployer <NUM> is configured to deploy to either edge-based host systems <NUM> or cloud-based host systems <NUM>. Each RRF has its own minimum/maximum computing resources requirements (e.g., CPU power, computing power, RAM size, internal storage, external storage/flash, etc.). Together they constitute the configurable computing resource for the runtime system. The deployer <NUM> takes these resource requirements and finds a valid allocation in the host system <NUM> to execute the runtime operation properly. This can be formulated as an optimization problem.

With the introduction of software defined runtime according to the RSL as presented in the disclosed embodiments, each function of the set of RFFs is exposed to the user at a top level for ease in constructing and arranging the configuration of the runtime system interfaces which are applied at lower levels once compiled and deployed. In an embodiment, RRFs are instantiated, specialized, stitched, and stacked according to the RSL, as illustrated by the following examples. An RRF is instantiated in RSL using a keyword. For example, using a keyword "new", the following RSL expressions instantiate a Scheduling RRF object into a MyScheduler variable, and a Timing RRF into a MyTiming variable. MyScheduler = new RRF. Scheduler()
MyTiming = new RRF.

The specialization operation on RRFs can be executed via parameters when the RRF is already instantiated, or independently using the functions of the RRF object. For example, creating a dynamic non-preemptive scheduler can be defined according to the RSL as follows for an instantiated RRF:
MyScheduler1 = new RRF. Scheduler({"scheduler_type":"dynamic",
"preemptiveness":"non-preemptive"})
Alternatively, the RRF specialization can be defined according to the RSL by independently setting parameters as follows:
MyScheduler1 = new RRF. Scheduler()
MyScheduler1. setSchedulerType(" dynamic")
MyScheduler1. setPreemptiveness("non-preemptive").

The stitching operation on RRFs can be executed using a keyword in the RSL. For example, the stitching of a Scheduling RRF and a Timing RRF can be defined by a variable MyBasicRuntimeBehavior using a keyword "compose" as follows:
MyScheduler = new RRF. Scheduler({"scheduler_type":"dynamic",
"preemptiveness":"non-preemptive"})
MyTiming = new RRF. Timing({"timing type": "hard-real-time",
"time_resolution":"<NUM>"})
MyBasicRuntimeBehavior = compose(MyScheduler, Mytiming).

The stacking operation on RRFs allows reuse of functionality. Stacking capabilities can be created as reusable modules according to the RSL. For example, a basic runtime behavior variable MyBasicRuntimeBehavior can be encapsulated in a module using a "compose" keyword according to the following RSL expressions:
Module SchedulingAndTiming {
MyScheduler = new RRF. Scheduler({"scheduler_type":"dynamic",
preemptiveness": "non-preemptive"})
MyTiming = new RRF. Timing({"timing_type":"hard-real-time",
time_resolution":"<NUM>"})
return MyBasicRuntimeBehavior = compose(MyScheduler, Mytiming)
}
After a module is created, the stacking operation can be completed using a keyword (e.g., a "compose" keyword). For example, stacking a Logging RRF on top of a SchedulingAndTiming functionality provided by the Module above can be done as follows:
MyLogging = new RRF. Logging({"compression":true})
MyBasicRuntime = SchedulingAndTiming()
MyComplexRuntime = compose(MyLogging, MyBasicRuntime)
Note that this pattern can be repeated as many times as needed, thus providing unlimited layering and stacking functionality.

In an embodiment, the runtime system can be automatically generated by algorithms and tested with intended applications. AI techniques can be used to learn the optimal way to compose RRFs of the runtime system, including the stitching, stacking and specialization operations as described above. An AI pipeline can be trained to produce the optimal RRF parameters and RRF configurations for the runtime system that are suitable for its specific usage (e.g., a software dashboard for a cutting machine, or a specialized audio diagnostic application). An advantage of using an AI pipeline for optimizing the runtime system parameters is the ability to quickly solve for parameters of disparate application requirements.

<FIG> illustrates an example of visualization display for development of the runtime system in accordance with the embodiments of this disclosure. During development of the runtime system, a user interface <NUM> may be configured to display information to the user as a dashboard presentation of RRF configuration status, which can accelerate the runtime system composition time. For example, a workspace template <NUM> may be displayed to show the set of available RRFs, such as those presented in Table <NUM>, and stored in RRF database <NUM>. A list of instantiated RRFs <NUM> may be displayed to track the RRFs that have been defined so far. One or more specific runtime system dashboards <NUM> may be displayed, such as for Runtime_B as shown. In an embodiment, when adapting a new runtime system from an existing runtime system, two such dashboards <NUM> may be displayed, one for each respective runtime system. Tracking of specialization operations may be displayed as a list of specialized RRFs <NUM>. Similarly, tracking of stitching and stacking operations may be displayed as a list of stitched RRFs <NUM> and a list of stacked RRFs <NUM>, respectively. Display <NUM> illustrates an example for how a list of stitched RRFs <NUM> may be displayed. The lists <NUM>, <NUM> for stacking and specialization operations may be presented in a similar manner. In an embodiment, a user accesses the runtime system configuration using the interface <NUM> at any time during the lifecycle of the runtime system, such as during development, testing, and after deployment. Such access permits modification to the runtime system configuration of RRFs, even while the automation is operational.

In summary, the disclosed embodiments for adapting a reconfigurable runtime system using reusable runtime functions include the following advantages over prior art.

Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase "based on," or variants thereof, should be interpreted as "based at least in part on.

Claim 1:
A system for constructing a reconfigurable runtime system used in an automation system using reusable runtime functions, RRFs, comprising:
a memory (<NUM>) having modules (<NUM>) stored thereon; and
a processor (<NUM>) for performing executable instructions in the modules (<NUM>) stored on the memory (<NUM>), the modules (<NUM>) comprising:
a specialization module (<NUM>) configured to execute a specialization operation to configure or customize at least one RRF to satisfy functional requirements of the automation system, wherein each RRF is definable with selectable options for functions and subfunctions, and wherein the runtime system includes at least one scheduling RRF (<NUM>) defined such that resources are allocated using dynamic hard non-preemptive scheduling, at least one timing RRF (<NUM>), and at least one logging RRF;
a stitching module (<NUM>) configured to execute a stitching operation that connects output of the at least one timing RRF (<NUM>) to input of the at least one scheduling RRF (<NUM>), allowing timing information output by timing RRF (<NUM>) to be input for scheduling RRF (<NUM>); and
a stacking module (<NUM>) configured to execute a stacking operation that stacks the at least one logging RRF on top of the at least one timing RRF (<NUM>) configured as hard real-time, or on top of the at least one scheduling RRF (<NUM>) configured as preemptive dynamic scheduler, wherein the at least one logging RRF provides logging capabilities of data generated by the underlying RRFs (<NUM>, <NUM>) as layers to create new abstractions, functionality and services;
wherein the specialization operation, the stitching operation, and the stacking operation are each executed using one or more keywords according to a runtime specification language, RSL.