Home Download Register Become an Affiliate Contact
Main Menu
Welcome to the LabHSM Toolkit Home!
What's New in Version 1.1
Why Active Objects and HSMs?
Universal HSM Template
LabHSM Editor
Getting Started
Included Examples

Just Think About It!
Most of the systems you deal with are reactive. But most likely, they can have something happening inside them even when they are not processing messages received from outside. Right? Moreover, most likely, they consist of subsystems that are reactive too and, in turn, can have their own "life", to an extent independent from other parts (with which they still communicate, of course). Such systems are more naturally modeled with active objects. So, why then should we try to model and code them with GOOP and its passive ("dead"!) objects?

"Flat" State Machines have been known for decades to have severe limitations. It's been more than 20 years since Dr. Harel invented hierarchical state machines (statecharts) to fight those limitations.  Then why should we be stuck with the same old Moore automaton still presented by some as the ultimate tool for event-driven programming in LabVIEW™?


PLEASE READ THIS FIRST: As one can see in the copyright line in the bottom of this page, this site was created in 2004-2005 to promote LabHSM toolkit for National Instruments LabVIEW "system design" software. Please note: this had happened long before NI created even its Statecharts toolkit for LabVIEW, let alone their heavy push for object-oriented programming much later and implementation of Actor Framework only very recently.

The only add-on product for LabVIEW related to the concepts implemented in LabHSM NI had then was a very primitive State Diagram toolkit which did not support state nesting (hierarchy). Despite the existence of that toolkit, in their training materials NI presented the most primitive Moore state machine as THE state machine all developers should use, not even mentioning Mealy.

The LabHSM toolkit used a little of VI Scripting. It had been already discovered by the developers community in LabVIEW 7 because somebody at NI forgot to password protect one of the VIs shipped with it, but at that time NI had no intention to allow the access to VI Scripting for developers outside of the company. After they tried to hide VI Scripting again in LabVIEW 8 in 2005, the author restored the access for the community with his Property and Method Selection Assistant.

Of course, today the LabHSM toolkit by itself has not much value. But the concepts and ideas which led to its development remain very useful. In fact, they are even more important today when "applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday’s software architectures". Therefore, I am actually happy that NI eventually recognized that by implementing Statechart and Actor Framework toolkits deeming LabHSM obsolete.

The sole purpose of putting this site back online today is for the author to show to prospective employers one of his contributions to the LabVIEW programming field. So, only some external references, contact info, etc. have been updated. Otherwise, the site looks the same as it did in 2005.

A Simpler and More Robust Way to Implement Non-Trivial Event-Driven Applications in LabVIEW™
LabHSM is a professionally designed toolkit that allows creating complex event-driven LabVIEW™ application as an easily maintainable collection of asynchronously communicating active objects ( actors ) based on a universal Hierarchical State Machine ( HSM or statechart ) template. The LabHSM  toolkit enables the programmer to work on a higher level of abstraction and utilize agile software development methodologies combining design and coding in one highly flexible process.

Version 1.1 is available now! Download it today!

Could your company (US or Canada) use the services of a National Instruments Certified LabVIEW Developer and NI Week winner in the R&D/Lab Automation Category? Click here for resume!


The implementation basically follows Dr. Samek's Quantum Programming paradigm. However, LabHSM stores the behavior information in a file separate from the code itself.  It also adds state dependent priorities to events, a separate queue for public events/messages, and, of course, some LabVIEW™ specific code like capturing front panel user events and putting them into the private Events queue. Communication and instantiation functions are also rather specific for LabVIEW™.

The LabHSM toolkit features:

bullet Active objects (a.k.a Actors) - much better and natural modeling of the real life objects than traditional OOP objects.
bulletUniversal messaging system - post events to self, send them to another object on the same system or across the world.
bulletPowerful hierarchical state machine paradigm, free of the limitations of a traditional, "flat" finite state machine, namely, combinatorial state space explosion and the lack of ability to consider the behavior logic on different levels of abstraction.
bulletAll the information about behavior of an active object is abstracted into a set of data structures and stored in an external file - no spaghetti or deeply nested code anymore!
bulletDesign is code! Modified behavior becomes code automatically as soon as the HSM file is saved.
bulletA universal template provides code structure that stays the same regardless of specific functionality. So all the code has basically the same look and feel.
bulletThe diagram structure does not have to change whenever you change the behavior.
bulletSqueeze more functionality into your VIs without creating more mess.
bulletCode reuse within the same VI. The same segments of code (actions) can be scheduled to run in different transitions in a mix and match fashion, even more than once in a single transition if desired.
bulletBehavioral inheritance allows substates to define only differences in behavior from their superstates. Inherit, augment actions, or completely override in a substate transitions defined in its superstates.
bulletTransitions can be defined to lead to the target state itself, its lowest default substate, or its history or even deep history, which enables even more concise HSM description (fewer states needed).
bulletReady to use external timer functions. Call a timer creation function and let the timer send events to your active object just like other regular active objects do.
bulletActions queue and a prioritized private Events queue provide a Run To Completion execution free of concurrency hazards.
bulletA separate public Message queue to ensure encapsulation principle is always observed.
bulletA powerful specialized editor for creating and modifying external behavior data files.


LabVIEW Webring

[ ... Back | Join Now | Forum | Featured Sites | Forward ... ]
Labview Directory

Universal HSM Template | LabHSM Editor | Getting Started | Tutorials | Included Examples | Links/References
© 2004-2005 H View Labs, Inc. All rights reserved.