TaskScript Features

TaskScript is an innovative methodology and technology for the development of Embedded Systems (actually, for the more general class of Reactive Systems) that allows designers to work exclusively at the graphic level, following to a model based approach. No programming is required, at all: unlike other technologies, TaskScript generates the whole machine executable code out of the model, without the need to tweak or even review the work. As a consequence, developers are not requested to be expert in programming.

The TaskScript technology is effective in the development of a wide range of control and observation devices used in Industrial Automation, Home and Building Automation, Traffic and Vehicle Automation, Appliances, Remote Agents, Internet of Things, Machine to Machine interfaces, and more.

The main practical advantages introduced by the TaskScript true model based development methodology are:

  1. strong reduction of the development effort, along the whole product life-cycle of an application; a rough estimate of cost reduction brought in by TaskScript is in excess of 15 k$ per year per seat; see below the case study for the discussion of such an estimate;
  2. strong reduction in the time to market of a product release (from months to weeks);
  3. higher flexibility in the management of the development team; this is due to the easiness to understand someone else's models rather than someone else's code;
  4. empowerment of domain experts in the development of their own applications, without needing the "mediation" of software experts.
  5. higher independence of model designs from a particular hardware.

Two are the main technical components that embody the TaskScript development methodology: the TaskScript Studio IDE (Integrated development Environment), a graphical environment that supports the whole development life cycle and the TaskScript Kernel, a run-time module installed onto the target microcontroller that supports the machine code generated by the IDE out of the model to operate.

TaskScript Studio is powerful graphical model based development environment running on PC under the MS-Windows® Operating System (supported versions range from Windows '98 to Vista versions); it supports the whole product life cycle of an Embedded application, and in particular:

  1. Design of the application, graphical model based;
  2. Debugging through simulation, at model level;
  3. Machine Code Generation, according to the selected target processor/board;
  4. Deployment onto the selected target board;
  5. Physical level Testing, at model level;
  6. Diagnostics and Maintenance.

The TaskScript Kernel is a kind of lightweight Operating System that helps the machine code generated by the IDE out of the model to perform the intended behavior; its main purpose is to abstract the implementation details related to each microcontroller/board to a higher, more uniform level; in particular, its main duties are:

  1. the scheduling of sequential and parallel activities (e.g. the Steps), as defined at model level;
  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 Protocol, used at run time for deployment, debugging and diagnosis purposes.

As the TaskScript Kernel has been developed natively at Assembly level for a number of microcontroller families, it is highly efficient.

Actually, 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 or PIC18 families, running on OS-less boards up to powerful boards equipped with high performances microprocessors running full OSs.

Boards equipped with PIC16 and PIC18 microprocessors are available, capable of handling both Digital and Analog I/O (digital I/O signals are reflected in the model into Boolean variables, while analog I/O are reflected into the model as 2's complement arithmetic variables). On such boards, a medium sized model, with 25 among digital and analog I/Os and a few Steps active at the same time out of 20 Steps overall has a scan time (e.g. the 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.

A Case Study

In order to better show the value added by TaskScript within the development life cycle of Embedded Systems applications, a case study is reported. The System to be developed is the controller of a 4 floors Lift: it ia a simple but not trivial application that uses 24 inputs and 12 outputs, all Boolean.

In order to keep the discussion simple enough, not all the concepts and technical terms referred to in this section have been introduced; please refer to the section dedicated to the Technology for a more rigorous definition of the terms and concepts.

The picture shows one of the possible solutions, which structures the controller logic into 6 main states (modeled in TaskScript as 6 Steps). The initial state (the double framed one) is the one in which the lift is at ground floor with its doors opened; this is the state in which a command is waited for, be it from within a car (user entered in the lift at the floor) or from another floor (user calling the lift at his floor); here the decision is taken whether to move and in which direction.

As soon as the decision to move has been taken (any direction), the state "Closing" is entered, which waits for the doors to close.

As soon as the doors have been closed, the lift moves in the requested direction, until the desired floor has been reached; at that point the state "Stop_DrOpening" which opens the doors; now the lift is at the desired floor, waiting for a new command.

The picture that follows shows the Transfer Function of the DoorOpened Step (that is the initial Step); notice the fair amount of logic, needed to determine whether a request (if any) means going up or down with respect to the actual position.

The transfer functions of other Steps in the model are simpler that the previous one; for example the Transfer Function of the Step GoingUp is as follows:

The picture that follows reports the result of one simulation. The simulation was performed with an option unique to the TaskScript environment (e.g. Environment), that allows to describe with the same formalism (that is the TaskScript Model Language) both the controller and its environment. For this simulation, a case was simulated in which a user first calls the lift to floor #2, then goes to floor #3 and finally goes to floor #4.

After the simulation phase is completed and the designer is satisfied with the simulation results, the controller is ready to be uploaded to a physical TaskScript board and be connected through its I/O signals to the physical environment.

Of course a real controller for a lift would be more sophisticated and include a number of emergency measures that in this case have not been considered. However, such an example is reported to give a first idea of how the TaskScript technology can be used and how it could reduce the development effort.

After having implemented such an example, a comparison among development effort and requested skill for three different approaches is reported. The compared effort is the one necessary to build the whole proposed system, including debugging and testing, and install it onto an Embedded System able to run it against the electrical signals.

 

 
C, C++, Java
Assembler
Development Effort
3 Man Days
2 Man Weeks
1 Man Month
Developer Skill
1 Month
6 Months
1 Year

 

Extrapolating from the above table, a conservative estimate of the cost saving in the development cost of Embedded Systems applications is in excess of 15 K$ per year per seat.

Further detail about the TaskScript design methodology can be requested via e-mail to cto<AT>taskscript<DOT>com (this e-mail address is protected from spam-bots: just substitute <AT> with @ and <DOT> with .).