TaskScript Technology

The main technical components that embody the TaskScript development methodology are the TaskScript Studio IDE (Integrated Development Environment), a graphical environment that supports the whole development lifecycle and the TaskScript Kernel, a kind of lightweight Operating System residing onto the target microcontroller that helps the code generated out of the model to perform the intended behavior.

Before covering the details of the above mentioned technical components, it is necessary to discuss the TaskScript Modeling Language, that is the foundation of the whole TaskScript design methodology.

1. The TaskScript Modeling Language

Within the TaskScript language a model is expressed by means of two "orthogonal" views: the higher level one is focused on the system behavior, while the lower level one is dedicated to model the data transformations that take place within the system under its various states.

The two modeling views combine together in a synergic way into a single formalism; the consistency between the two views is enforced by the IDE:

1. A hierarchical, generalized State Based formalism is used for the definition of the Control Flow(e.g. the dynamic behavior of the system), with possible parallel threads and synchronizations among them; the atomic entity of the Control Flow Diagram is the Step; Steps are connected by guarded Transitions: as soon as a Guard is true within an active Step, the respective Transition is “fired”: the Source Step becomes inactive and the destination Step becomes active. At each time one or more Steps in the system can be active; this capability eases the implementation of applications that need to control inherently parallel systems. Designs can be modularized by means of the Task construct. Steps are the atomic entities for the Scheduler of the Virtual Machine; they are evaluated cyclically in a round robin way lasting forever; the transition Guards of each Step are evaluated at the end of the Step. The picture below shows an example of the Control Flow view; notice the initial Step (e.g. the one with the double frame), the presence of two parallel threads (originated by the thick double bar) and finally the use of a Task (e.g. st_TSK1) wtich encapsulates a portion of the system behavior.

   
2. The “internal behavior” of each single Step is modeled using the Data Flow Diagram: it specifies the mapping among (a subset of) the system variables (both Boolean and Arithmetic types) that
   is established as soon as, and as long as, the Step is active; following the analogy with logic networks, such a mapping can be referred to as the "transfer function" of a Step. Transfer functions can be, in turn, specialized for the first time one Step becomes active (e.g. On Entry Transfer Function, ecexuted once when the Step is activated), the last time one Step is active (e.g. On Leave Transfer function, executed once after the Step has been deactivated) and unless the above two conditions are true (e.g. the normal Transfer Function - defaut). The primitives available for defining Transfer Functions allow to express all the Logic and Arithmetic transformations between data, being them scalar and arrays; a non exhaustive list of operators include: Logic Gates, ALU, Delays, Shift/Rotates, Multiplexers, etc. The picture below shows an example of the Data Flow view; notice the "natural" integration among boolean variables and operators (thin wires) and arithmetic ones (thick wires): the output of a comparator is a boolean variable, while the select of a two way arithmetic multiplexer is a boolean variable.

The use of two modeling views, the former mostly dedicated to partition the system into smaller complexity Tasks and to express the control of each Task as possibly parallel sequences of Steps, and the latter mostly dedicated to express the transformation of system variables that take place within each Step, synergically integrated into one single formalism, gives the language a really high expressivity while keeping its use straightforward and efficient even for complex applications.

The whole modelling language supports both the textual and the graphical form; actually the TaskScript Studio IDE lets designers operate at graphical level only, maintaining automatically the textual form without even expliciting it to the user.

As it has been shown by the picture, the formalism chosen for the Data Flow view exploits the analogy with arithmetical and boolean operators. The analogy is complete: whichever (legal) network of devices is drawn, it will produce a Transfer Function in the synthesized software whose behavior is strictly adherent to the expected behavior of a (ideal) network made of the respective physical elements.

The formalism used in the Control Flow was first proposed by the Grafcet group (in France) in the seventies (and later standardized as IEC 848); actually it can be seen both as an extension of the State Machines concept, to allow parallelism, and a simplification of the Petri Nets formalism, to keep it simpler; the resulting formalism is straightforward and easy to understand by the average designer.

As a whole, the TaskScript Modeling Language can be compared with two of the five languages proposed in the IEC 61131-3 standard, although the standard refers exclusively to PLCs while TaskScript is oriented to the wider class of Reactive Systems: the Control Flow is similar to the language called Sequential Function Chart (SFC) in the norm (they both derive from Grafcet); the Data Flow is can is similar to the language called Function Block Diagram (FBD) in the norm.

However, while inheriting a large part of the theoretical background from the IEC 61131-3 standard and its own ancectors, the TaskScript Modeling Language was deliberately designed to address the larger class of Reactive Systems, including the ones built with low performace (and low power) CPUs, at the sacrifice of not being strictly compliant with the norm. In the following, the main optimizations over the norm are listed:

1. only 2 views are used: Control Flow and Data Flow (accomodated within one single language) since their combined use was considered synergical for the effectiveness of a model and for the efficiency of its implementation for all the spectrum of physical implementations;
2. the whole language can be expressed in both graphical and textual representations, the former being optimal for model development (design, debugging, etc.), the latter being used internally, for the compilation and code generation process; the derivation of one representation from the other one is governed by simple rules.
3. a number of reciprocal constraints has been imposed among the two views, enforced by the IDE;
4. the number of data types has been reduced to the ones shose implementation is the most efficient one;
5. the resulting language is truly declarative and, as such, easily processable by available model checkers in order to obtain the automatic check of properties over the model;
6. a simpler IDE could be built and learned by users.

2. The TaskScript Studio IDE

The TaskScript Studio IDE (Integrated Development Environment) is powerful graphical model based development environment that supports the whole product lifecycle of an Embedded application, and in particular:

1. the design of the application, model based;
2. the debugging through simulation, at model level;
3. the generation of code for the target processor/board;
4. the deployment of the code to the target processor/board;
5. the testing of the design within the physical environment, at model level;
6. the diagnostics testing of the physical environment for maintenance.

As already pointed out, the whole design process takes place at the model level, without the need of "going below the model level", that is to tweak or even to look at the code that was generated out of the given model.

In the following, a typical design path is considered, starting from model design all the way to the deployment of the model onto the physical system, at the purpose of illustrating in detail the strong support offered by TaskScript Studio to designers.

The picture below shows a typical TaskScript Studio screen during the editing phase.

Three graphic windows are shown in the picture, showing the 3 main editing modes of TaskScript Studio; from left to right there is: (1) the Context Diagram of the design (the model's top level view), where the Tasks are defined and global variables are declared and possibily allocated; (2) the Data Flow view for Step main.ST_38 and (3) the Control Flow view for the Task main, containing Step ST_38 and an start of Task TSK1 (named st_TSK1), among others. For each editing mode a different palette is available (see the rightmost part of the picture); the one shown is the Data Flow palette.

Within all the views, all the basic editing options are available, such as cut, paste, copy, drag, multistep undo, alignment, zooming, etc; left clicking on any drawing element pops up a menu of properties specific to that kind of element(e.g. one of the specific properties of an ALU module is its operation: available choices are: Sum, Subtract, Multiply, Divide, Modulo, bitwise And, Or, Exor); right click to any drawing object pops up a general purpose menu of operations.

Right clicking upon a port of an element will activate a rubber band wire, that can be terminated dropping it onto another port (connections rules must be satisfied, like port type and direction compatibility).

Once drawn, the model can be simulated, in order to check its actual behavior and spot possible flaws in the design. Simulation is usually performed modeling the sensor periphery within TaskScript Studio and "connecting" the model of the Reactive System with the model of the sensor periphery. This is what is called Environmental Simulation; in other words, taking advantage of the easiness of use of the TaskScript Modeling Language, the sendor periphery is modeled as well (kept apart from the "real" Reactive System, placed in a different Task of type "Environment"; this task will be used for simulation purposes and then discarded when generating the code for the real Reactive System to be deployed onto the target board).

Simulation is performed compiling the model and executing the generated (Virtual) Machine Language form on a special TaskScript Virtual Machine running on the TaskScript Studio PC; such a special virtual machine, instead of interacting with I/O signals, generates a simulation trace that can be loaded and traversed by the Studio.

Two are the ways in which the trace can be visualized:

• Structural simulation, where different modules of the system can be opened on the screen (e.g. Control Flow and Data Flow segments) and, for each frame of the trace (e.g. point in time) the state of the various elements is shown with a colour coding (e.g. red is False/Unactive, green is True/Active, cyan is First activation, yellow is Last scan); the whole trace can be traversed, from the fist frame to the last one, in order to understand the very detail of the model behavior. The following picture shows a structural simulation within TaskScript Studio; notice the colour of the various model elements and, on the very right, the buttons that allow to traverse the trace frames (e.g. go to the desired point int time).

• Temporal simulation, where a selected set of variables can be displayed over time, such as traces on an oscilloscope. Traces can show both boolean and arithmetic variables, as well as the state of Steps. The following picture shows a temporal simulation within TaskScript Studio; notice that the upper four traces refer to the state of four Steps, while the lowe one refers to the value of a boolean variable.

After the model has been verified an deemed correct, the generation of the actual executble code out of the TaskScript (Virtual) Machine form can take place; notice that the compilation phase (e.g. the generation of the TaskScript (Virtual) Machine form) is shared with the simulation; however, if the model contained Environment Tasks and other checking instrumentation, they are left out before this compilation.

The TaskScript Virtual Machine form is then expanded as needed acording to the target processor/board; such an operation is actually a macro-assembly step, where each Primitive of the TaskScript Virtual Machine is replaced by the respective sequence of low level operations of the target microprocessor, with possible calls to helper functions residing in the TaskScript Kernel. The expanded code is then assembled and an executable code is produced, ready to be uploaded to the target microprocessor.

All the above mentioned process takes place automatically and needs only the selection of the desired target processor/board.

Boards equipped with the pre-installed TaskScript Kernel are ready to run the generated code, since the Kernel has built-in the helper functions needed to support the TaskScript Virtual Machine Language.

The Deployment of the executable code to the target board iis one of the verbs defined in the Development Protocol (other verbs are the download the actual state from the controller, the start and the stop of the controller); such a protocol allows communication among TaskScript Studio and the TaskScript Kernel installed onto a physical board; the communication can take place over various means; however, for the simplest boards an RS-232 interface is used; hence the PC hosting the Studio must have a serial interface (in case it does'nt have one, a USB-to-RS232 cable could do the job, as well) and the two must be connected by a RS-232 cable.

In order to allow the TaskScript Kernel to service the Development Protocol, the "Load/Run" switch must be placed in the "Load" position. The actual steps are as follows:

1. connect the board with the PC by means of the RS-232 cable;
2. set the interface options in the Studio as appropriated: choose the COM port and type (e.g. Galvainc or Optoisolated) according to what is available on the target board;
3. power the board and set the "Load/Run" switch to the "Load" position.
4. click the Upload button on the Studio IDE.
5. After the upload is finished, set the "Load/Run" back to the "Run" position to restart the controller: the target board is now behaving as specified in the uploded model.

The picture below reports an advice that pops up after step 4.

Testing of the model at physical level, as well as physical Diagnostics are the other features supported by the Development Protocol; loke the download, they can be performed within the Studio provided that the board is connected with the PC through an RS-232 cable and the the "Load/Run" switch is placed in the "Load" position.

The two operations leverage upon the ability of the Kernel to answer to a query of the PC sending back the whole state of the controller at the time of the query. The state is received by the studio, shown on the screen in the same form as a Structural visualization (actually, in this case the colouring reflects the actual state of the controller) and appended as a frame to a trace file for further navigation.

Having access to the actual state of the model when immersed into its actual physical environment opens the two above mentioned features:

1. the verification that the controller is behaving correctly also with the real environment and not only with the simulated one
2. the verification that the environment is working properly (being it made out of electro-mechanical parts, it can break easily than the controllerf itself); this is useful especially in the servicing phase, where the controller is used to verify the electro-mechanical components it is working with.

3. The TaskScript Kernel

The TaskScript Kernel is a lightweight Operating System residing onto the target microcontroller that helps the executable code generated by TasjScript Studio out of the model to perform the intended behavior on the target board.

At run time, on the target microcontroller, 2 pieces of software are tigthly cooperating in order to have the physical board strictly reproduce the behavior contained into the model:

1. the Kernel, permanently resident upon the miccocontroller which abstacts the peculiarities of each microcontroller/board and of its resources (such as its I/O and timong interfaces) to a higher common level;
2. the code generated out of the user defined model whose purpose is to reproduce the desired behaviour, using the support of the Kernel.

The Kernel code has the highest efficiency, being written in Assembler native for each microcontroller family it has been ported to; on the other hand, the code coming from the model is also very efficient, since it derives from a compilation of the TaskScript Model Language into the TaskScript Virtual Machine form (the two languges have been designed in order to be perfectly adapted one to the other, hence the translation produces a highly efficient form) and the TaskScript Virtual Machine form is translated into executable code by means of a macro-assembly step.

The main task performed by the TaskScript Kernel include:

1. the scheduling of sequential and parallel activities as defined at model level; a simplified description of the evaluation algotirthm is the following: the scheduler considers the list of active Steps and evaluates their Transfer Function once, in a round robin way; at the end of the list it updates the list of active Steps (future state) and, after having refreshed the I/O signals the scheduler starts a new evaluation of the list of active Steps.
2. the binding of the hardware resources, (such as the I/O interfaces with the electric signals, both analog and digital, timing and communication resources, long term memory, etc.) to the variable system which has been defined in the model language;
3. the management of the Development Procotol, if enabled by the "Load/Run" switch.

The picture below illustrates a detail of the scheduling algorithm implemented by the Kernel, showing the operations performed during one scan. The various phases are: (1) update of the state of Steps for the current scan, (2) storage of last scan values, (3) sample of input variables (4) reset of non retentive variables, (5) evaluation of Transfer Functions of each and every active Steps, (6) update of timing, counter and communicator resources, (7) refresh of output variables.

The whole TaskScript Technology has been designed to maximize the performances for physical implementations ranging from low-cost low-energy consumption 8 bit microcontrollers like the PIC16 familiy runnig on OS-less boards up to powerful boards equipped with high performances microprocessors running full OSs.

In order to give an estimation of the available performaces, a medium sized model, with a few Steps active at the same time out of 20 Steps has a scan time (time needed to evaluate once the Transfer Functions of all the active Steps) of less than 1 mS on a PIC 16 board; the same model has a scan time of less than 0.2 mS on a PIC18 board.

Such performances make TaskScript a unique and powerful technology to develop very low cost controllers able to manage a huge range of physical systems.

Further detail about the TaskScript technology can be requested via e-mail to cto<AT>taskscript<DOT>com (this e-mail address is protected from spambots: just substitute <AT> with @ and <DOT> with .); click here to quickly to send a request.