The Vision

(a vision paper written by the author of the TaskScript technology)

1. Introduction

One of the main objectives that the Computer Science has been addressing since its birth is the ability to develop software applications using languages and formalisms with higher and higher levels of abstraction, that is, to build programs (in today's words: IDEs: Integration Development Systems) able to automatically take care of all the implementation details and let designers concentrate upon the most important aspects of the problem.

Really impressive results have been reached since about fifty years ago, when the first FORTRAN (from Formula Translation) compiler ever implemented was optimistically called the “Automatic programming” program, to emphasize the significant rise in the programming abstraction with respect to the Assembly languages used until then.
Soon after that fundamental milestone was reached, it was realized that the task of programming was still well away from being automated.

Many other programming languages and methodologies have been introduced since then, at the purpose of allowing designers to express, challenge and verify the architectures and algorithms (in today’s words: the models) that they were conceiving as solutions for their current design.

Most of the proposed methodologies exploit analogies with other engineering disciplines (e.g. electric design) or introduce abstraction layers, (e.g. state machines) in order to let the designers visualize their models in the form of diagrams which, being graphical, are more understandable than a plain (e.g. monodimensional) sequence of instructions, as they are listed in a software program.

Following this path, the modern frontier of the Computer Science is the achievement of the "true model based design", that is a software development methodology (and technology) that lets designers model their solutions according to a high level (graphic) formalism and, from that description of the model, automatically generate the machine executable code of the modeled system, without any intervention required by the designer.

The envisioned way of using true model based design is like using a FORTRAN or any other higher level compiler: since few decades every programmer writes a program in one of such languages, runs the compiler and assumes that the generated executable code is correct, without bothering to check the produced executable code against its high level program (the bugs, if any, are to be found in his high level program, not in the translation, which is assumed correct).

The lately introduced design methodologies, such as the OMT and UML, offer a wide number of different kinds of abstractions (e.g. views), in order to let designers chose the most appropriate view for modeling the case at hand. Such methodologies are very general: they are aimed at the design of a really broad range of systems; this can be one of the reasons why they are not (yet) true model based design systems: no real software has already been built working entirely at the model level, without going "under the model" and reviewing (e.g. adding detail or tweaking) the generated code before it is compiled into an executable program.

While for the general case we are still away from the "true model based design" target, for specific classes of systems, architectures and design methodologies have been developed that allow to proceed automatically from the model level to the implementation level, with synthesis algorithms taking care of the definition of all the implementation details until the machine executable code is generated.

This is the case of Data Base applications, where the Entity-Relationship formalism allows for the design of the final program by modeling it at the E-R level, either in a textual or in a graphic way.

To name another example, somehow closer to the Embedded Systems domain, that is the focus of this paper, the Ladder Logic, used to program Programmable Logic Controllers, allows the modeling of a programmable controller as a network of switches; the state of any switch (e.g. open or close) is set according to the value of a boolean signal connected to the controller or the value of an internal variable; such a network is compiled into a running program without need to review the produced code. However, such a formalism is too simplistic and the class of systems that can be modeled is too narrow with respect to most real systems; extensions to this formalism exist that allow the modeling of a broader class of systems but the analogy with the physical world becomes weaker and weaker, and this vanishes the benefit of working at the model level.

The VHDL language, as a final example, although focused to hardware design (namely VLSI Integrated Circuits such the microprocessor themselves), is true model based: it allows designers to model systems according to a really extensive set of primitives, working at four levels of abstraction; however, due to the wealth of details that must be considered when designing real hardware systems, it is out of reach of the majority of the embedded designers, whose knowledge is more focused on the application domain.

The main practical advantages brought to the industry by the true model based approach are:

  1. strong reduction of the development effort, along the whole product lifecycle of an application; a rough estimate of cost reduction brought by the true model based approach is in excess of 15 k$ per year per seat;
  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.

2. An innovative software development technology for Embedded Systems

Development of Embedded applications is typically harder than "non embedded" (e.g. PC based) ones, because the produced code must be optimized with respect (to at least) processing power, used memory and energy, which are limited by physical constraints: such aspect are less important for "non embedded" applications, where the always growing power of off-the-shelf computers could mitigate some less-than-optimal synthesis from the model.

Also for the above mentioned reasons, software development of embedded systems is still carried out by writing a program in textual form (possibly integrating assembly modules with higher level ones), debugging and testing it the way that software is being developed since a couple of decades.

The vision behind the TaskScript methodology and technology is to bring the true model based approach to the software development of Embedded Systems so that, in the next few years such an approach will become the standard way of designing most of the Embedded Systems applications.

Such a private research project, started more than a decade ago, was driven by the following major guidelines:

  1. restrict the general domain of handled systems to the one of Reactive Systems (a Reactive System is a system (Hardware + Software) able to observe and control a large number of physical devices, applying the desired algorithms to determine the values to send to the controlled devices out of the values received from the observed ones);
  2. define the Modeling Language in both its textual and graphical forms, in such a way that switching from one form to the other can be defined by a simple set of rules and can take place without loosing information (apart from the physical positions of the graphical drawing); such a Modeling Language should be on one hand expressive enough to allow the modeling of all the interesting classes of systems and, on the other hand, easy enough to be used by the majority of the designers and, finally, compilable into efficient machine code even on low-power low-energy microcontrollers (e.g. 8 bit microcontrollers).
  3. define the Virtual Machine Language (e.g. the lower level language in which models are translated by the compiler: a common abstraction of all microcontrollers) in a way that all its data types and primitives can be implemented in an efficient way also in low-end microcontrollers.

According to the above definition, the class of Reactive Systems covers a broad range of devices used in Industrial Automation, Home and Building Automation, Traffic and Vehicle Automation, Appliances, to cite only the most straightforward examples. To mention another example, the "Things" of the "Internet of Things" are most probably controlled by Reactive Systems.

It can be noticed that the classes of Embedded Systems on one side and the one of Reactive Systems on the other side are not completely coincident, since some Reactive Systems exist that are not implemented as Embedded Systems (e.g. they are implemented using just a "regular" PC) and also some Embedded Systems exist that are not only Reactive (e.g. the majority of their functions are dedicated to information or signal processing, rather than device control; this is the case of cameras, VCRs, cellular phones and other infotainment devices).

However, the fraction of Embedded Systems that are also Reactive Systems is so large that in the following the two classes will be considered synonymous, keeping also in mind that TaskScript can also be used for Reactive Systems running on "non embedded" systems (e.g. the PC).

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 lifecycle and the TaskScript Kernel, a run-time module installed onto the target microcontroller that supports the code generated from the model to operate.

Both components have been designed in order to achieve the highest efficiency in the generated machine code; the TaskScript Kernel has been developed natively at Assembly level for a number of microcontroller families; this allows TaskScript to perform well also for low-cost low-energy consumption microcontrollers like the PIC16 and PIC18 families. Please refer to the Features section of the site for an overview and to the Technology section of the site for a detailed description of the TaskScript design methodology and technology.

The current version of TaskScript, V.1.1.0, is fully functional and supports model based development as described in this paper; actually this web site documents this result at the purpose of spreading this technology.

However this result is only the first milestone of the vision behind TaskScript; a tight roadmap is under way in order to achieve a number of even more outstanding targets in the future months and years; the evolution of TaskScript will follow the main two directions:

  1. addition of new features to the modeling language and of new features to TaskScript Studio; among them:
    • integration of a Model Checker, in order to achieve the ability to formally check the correctness of the model against a number of "rules", both built-in and user defined.
    • integration of new "views" into the modeling language, at the purpose of easing the development of models (e.g. a new imperative view, with constructs like "if-then-else", "for", "while" etc., or other declarative views, like the Ladder Diagram, used in the low end PLCs).
    • finer qualification of Steps and variables, in order to allow designers to assign priority to Steps, in order to achieve shorter response times where/when needed.
  2. porting of the TaskScript Kernel to a wider range of reactive systems, and in particular:
    • rewriting it in the native Assembly language of other microprocessors; this is an effort consuming task but will yield the best results; it will be adopted for very popular low cost microcontroller families, according to customer needs;
    • writing it in high level languages (e.g. C, C++ C#, Java), in order to allow the porting of TaskScript upon higher level platforms, such as Win CE Embedded®, Symbian® or others; this way is easier and more general (one porting will fit many devices); however the performance price that will be paid in this case will be compensated by the availability of more powerful microprocessors.

3. TaskScript and You

At the end of the Introduction section a number of generic advantages of the true model based approach have been listed; TaskScript brings them all. In partcular, the sectors of industry that can benefit from TaskScript are mainly:

  1. Companies which buy and use off-the-shelf Embedded Systems (e.g. PLCs): for such a kind of companies TaskScript could become the technology of choice, since it will reduce two kinds of costs:
    • Non Recurrent Engineering: that is the effort of the development of a new application; a rough estimate in the saving brought in by TaskScript is in excess of 15k$ per year per development seat.
    • Recurrent: that is the cost of buying physical TaskScript systems; according to volumes TaskScript physical systems can be bought as:
      • finished controller boxes or boards,
      • microcontroller chips with pre installed the TaskScript Kernel, allowing customers build their own boards according to their specific needs
      • TaskScript Kernel licenses, allowing customers program the TaskScript Kernel on their own chips and build their own boards according to their specific needs.
    • The three options above have decreasing costs per unit with respect to other solutions; in all cases they are lower than the ones of other solutions (e.g. PLCs) mainly because, due to the high effectiveness of the modeling language, less resources are needed by a TaskScript model than other approaches, to implement the same application.
  2. Companies which build their own Embedded Systems for their own products: for such a kind of companies TaskScript could be the technology of choice, since it will reduce the Non Recurrent Engineering cost (that are the effort of the development of a new application): a rough estimate in the saving brought by TaskScript is in excess of 15k$ per year per development seat.
  3. Companies which build their own Embedded Systems as products for their customers: for such a kind of companies TaskScript could be the technology of choice, since it will raise the value of their products, in two ways;
    • selling Embedded Systems that can be programmed through true model based development, making their products appealing also to customers without deep experience in programming.
    • providing more powerful systems at the same price, since the TaskScript language allows to make a more efficient use of the controller resources.
  4. Companies which build Microprocessors, Microcontrollers or IP cores: for such a kind of companies TaskScript could be the technology of choice, since it will raise the value of their products providing a complete and integrated development environment; a CPU with the TaskScript Kernel preloaded could be programmed directly through true model based development, making it more appealing to a larger range of customers.

Since 2009 TaskScript is available for production, accompanied with a thorough documentation, that is a Reference Manual, a User's Manual and a Quick Start Guide.

TaskScript comes with different Editions, each one targeted to a particular customer segment (e.g. Home, Professional and Enterprise); besides the commercial editions, one edition is released free of charge since 2008; it is the Student Edition, given for evaluation and for other non commercial purposes (of course such edition does not support the code generation for a physical controller, but it is limited to simulation).

Integral part of the vision is to partner with companies implementing controller boards and chips, in order to implement new versions of the TaskScript Kernel compatible with their boards and chips; such new versions of the Kernel could support either the standard version of the TaskScript Virtual Machine hence immediately compatible with the Studio IDE, or a special version, to be used with an adapted version of the Studio IDE.

4. Conclusions

The paper discusses the vision that lays behind the TaskScript project, that is to enable the development of Embedded Systems applications working at model level only, in order to become over time the standard way of developing Embedded Systems applications.

Such a technology, started more than a decade ago and applied over the years to specific automation projects, is now ready for the general market.

In order to assess the real benefits introduced by TaskScript, two evaluation options are possible: the first one is to download free of charge the TaskScript Studio Student Edition from this site; the whole design process, from model design to the implementation of the physical system can be evaluated buying a low cost Evaluation Kit, containig the TaskScript Studio and a physical board loaded with the TaskScript Kernel. To request the evaluation material you can go to the Sample/Buy section of the site.