Skip to main content

High Level Logic

Posted by rogerfgay on July 30, 2010 at 1:30 PM PDT
Project URL

Go see Project Homepage


High Level Logic (HLL) is a framework for intelligent applications that is easy to understand and use, even by less experienced programmers.


StagingSource code is being cleaned up. First upload to this site expected by the end of August 2010.
First upload will include API (javadoc), browser-based GUI, and simple demo application in robotics.
Tutorial documentation is in the works and initial necessary documentation should be available about the time of first software upload.
Video tutorials are also planned.
HLL is written in Java; first release Java SE only. The current browser-based GUI (optional) that is provided requires Apache Tomcat for servlets.
Developer: Roger F. Gay

HLL, What is it and what is the vision?

High Level Logic (HLL) is a framework for intelligent applications that is easy to understand and use, even by less experienced programmers. Applications consist of integrated chains of decisions and operations (see below). Development of cooperating systems, each of which is built on HLL, is as easy as building a single integrated system. Application programmers build protocols that link to specialized application components. HLL "message passing" is taken to the extreme, as with independent interacting agents, while providing the backbone for complete applications around which specialized application components are applied and interact. Individual actors (intelligent agents) within the framework have specialized roles and responsibilities (and authorities) that are designed to complement one another. The HLL components form a complete working organization that controls, manages, and executes the "chains of decisions and operations" of the application.

History of the HLL concept to the current vision

The general idea was first conceived in the mid-1980s when AI - rule-based "expert systems" - were first becoming commercially available. The expert systems technology of the day was plagued with "bottlenecks" that limited much development to narrowly focused domains. The idea of tying individual rule-based experts (and other software) together with a software system modeled on human organizations seemed appealing. My use of the term "expert" expanded to include a wider range of specialized software components, including those that specifically integrated, traded, and made use of results from individual narrowly focused rule-based experts.

A specific problem that I soon found in front of me involved decision support for agricultural enterprizes - farms. One farming operation can consist of a variety of separate enterprizes, such as different crops and animal stock. Within each of these larger enterprizes, there are many narrowly focused decisions, such as feed, fertilizer, and irrigation optimization that were fit for narrowly focused expert systems. How can one integrate individual narrowly focused decision processes with other other dependent decisions? How can one integrate entire operations to optimize production and profit for the farm?

By the end of the decade and into the next, I had many discussions with academics and developers on a wide range of similar problems. One in particular sticks in my mind; that of automating entire factory operations, from field sales through front office, into production, to delivery and payment. It may have been through this conversation that my preference for actors and organization reflecting human roles and human organizations became locked in cement - so to speak. In this context, it hardly seems that any further explanation is needed for this preference (assuming you've worked in similar organizations or have some conception of how they work).

Today, the concept of software agents that perform tasks previously performed by specialized humans is not unpopular - such as an Internet salesperson, for example. One might also include those irritating automated telephone answering systems that try to figure out what you want and direct your call, perhaps to another automated system. Picking up the idea again in the late 1990s, it was not difficult to realize that using current technology, it is possible to create a much more powerful system much more easily than originally concieved more than a decade earlier. Java's network support for example (and the Internet of course), provides powerful ways for components to interact even when they are physically on systems half a world apart (or in outer space). Large enterprize systems (well supported by Java EE) can provide systematic interaction between departments and operations.

Yet, the problem that I generically refer to as "high level logic" is still with us. I spotted it immediately as I became involved in intelligent autonomous robotics. Many of the brilliant achievements so far deal with "lower level" (narrowly focused as with the expert systems before) functionality - balancing and walking, avoiding obstacles, moving through unfamiliar spaces, grasping objects (not prepropgrammed for the specifics as industrial robots) and the like, as well as automated learning, including automated creation and maintenance of control software. There has also even been some very interesting work at much higher cognitive levels - such as an experiment in development of Autonomous Moral Agents in one of my own organizations. (Publication in the works.) Technology for sophisticated cooperation between robots is still in very early stages.

Even when human agents are considered, it is possible to see the distinction between specialization and what I refer to as "high level logic" (my specific meaining). Inexperienced and uneducated people often have highly specialized jobs that involve narrowly focused repetative tasks. Education, training and experience are often involved before one integrates mastery of a chain of decisions and operations.

A new software engineer works on writing programs, initially focusing on smaller parts of larger systems under the direction of more experienced engineers. Years later, that same engineer may recognize a need, propose a design and a large project, complete its planning and manage its execution.

A 16 year old with a drivers license is known to feel hungry. Left to herself, the entire diet could well consist of twinkies, chips, and McDonalds hamburgers enough for one. A 45 year old wife and mother can make planning and execution of a large sophisticated social affair with a nice (and possibly healthy) dinner look easy - even fun. (At least the thinking part.)

I do not believe that we will see the kinds of sophisticated intelligent software systems that are dreamed of today without generalizing the organization and processes involved in integrating chains of complex decisions and operations. It is this part of intelligent systems design that the HLL concept seeks to address.

Power Point conceptual presentation from 2005

HLL SE, Version (0.4 - 1.0)

The version 1.0 release, HLL SE also code-named "HLL Light" is very light-weight, easy to master and use. It is intended to provide a quick-start into understanding and using HLL, yet provide a sufficiently powerful framework to be the right choice for a wide range of applications. Links to Sun Java "Trail" tutorials are included in project documentation (and at least a few HLL specific tutorials will likely be written) for programmers who wish to understand the HLL source completely but have yet to master some of the technology involved.

Although application developers can add whatever components they wish, HLL Light itself is intentionally restricted to Java SE components only and the organizational structure is fixed to three layers; "executive," "manager," and "experts." (Experts are merely specialized application components, although they may be "experts" or "expert systems" in the more traditional AI sense. More on that in other documentation.)

Interaction between these levels is controlled by a simple server (sockets). "Roles and responsibilities" or members of the organization are defined by application programmers in the form of server protocols; i.e. normal Java programs that determine what is to be done when an executive, manager, or expert is contacted via the server. (You do not need to have expertise in server technology to write your first protocols.) Most "experts" are application specific and must be created by the application developers or otherwise acquired (perhaps from another open-source project).

Short list of potential improvements:
  • Initilization with user defined configuration files, replacing required configuration files
  • A simple forward-chaining JSR-94 complient rule engine

Make a special note here, that the addition of some sort of rule processing system is a high priority for this project, especially in support of replacing the need to write complete server protocols in Java. (It will have other uses too.) Using this first release (a documented version of the first simple prototype), application builders who write complete protocols in Java may feel that they are writing too much of the actual "high level logic" themselves that should be done automatically as an advantage to using the HLL framework. (That shouldn't stop you though - here's a start - copy-paste and modify as many times as needed: if () {} else if {} else {} - but seriously, a rule system w rule construction tool built specifically for HLL will be a welcome addition. The EE version discussed below might use JBoss Rules instead.)

The version 1.0 release includes a simple example using two interacting copies of HLL Light, one supporting high level activity for a very simple robot simulation and the other supporting the robot's Command Center. HLL does not require an Internet server. The example can run using command line input. (*) But the example includes an optional browser-based GUI that runs under Apache Tomcat. It has applet-servlet communication that allows the robot to "push" information into the browser without an explicit request from a human operator. Communication between the GUI servlet and HLL Light occurs through a socket, keeping the HLL framework entirely separate from the GUI components.

Created as part of the development process, the example currently displays tracing information and simple animated graphics showing the robot's movement through rooms. Developers can however, easily modify the information sent to the browser using HLL methods. Documentation provides illustrations of the use of this GUI for end-use applications.

* Other applications can replace the command line interaction with interaction between HLL processes and other programs; and "other programs" can include other HLL based applications. Communication between the robot HLL and Command Center HLL is an example of this interaction.

HLL EE, Version 0.0

HLL EE represents the more powerful next generation version of HLL. Along with exceptional power and flexibility, experienced Java programmers and specialized teams should realize significant time savings in developing sophisticated applications along with appreciating enhancements through use of Java EE and other technologies.

The current short-list is given here. Suggestions are welcome, but there inclusion on this list is not guaranteed.
  • J2EE Java Message Service (JMS) to replace socket connections.
  • Generalization of organizational member definitions (open definitions not restricted to three)
  • JBoss Rules to replace the actor (organization member, roles and responsibilities) specification processing system.
  • In addition to Jboss Rules - or alternatively - write (or acquire in open source Java and integrate) a simple forward-chaining JSR-94 complient rule-processor with separate standard-complient (yet to be chosen) web resource definition approach to actor specification.
  • Other generic AI processing components (see below).
  • Enhanced inter-operability standardization (as in JAUS for robotics for example)
  • Enhanced security (including cryptography) for sensitive applications.
  • Generic (JDBC) front-end methods for database support?
  • GUI modification / replacement (possibly using portlets or jsp).

JMS provides point-to-point and broadcast communication, both asynchronously and in a limited precise sense synchronously.

JBoss Rules provides a powerful rule-processing system that is strongly integrated with Java. It is easily called, used, and modified from within another system and rules can be composed that contain Java method calls. (Simple example, something like: if (Obj1.method1) then (Obj2.method2).) It is noteworthy that the earliest conception of an HLL system occurred circa 1985 as a way of opening up the bottlenecks in "expert systems" development; early commercially available AI that was most often based on rules.

Consideration for GUI modification / replacement is based on the general difficulty of maintaining cross-browser applications and the availability of alternatives. (In fact, more work and testing is needed in this area. See below.) I think this one will ultimately depend largely on user preference and acceptance (or rejection) of the dhtml / frames approach.

Additional features.


Although the existing browser-based GUI is an extra free component, it is currently configured as a nice addition to the developers' suite, allowing complete system (something to the GUI at least) operation from the beginning of each development project. There is an intent to build generally useful and reusable functionality and to minimize effort in customization. (It's frames! So long as you have communication with the back-end processes, you just need to create specialized web-pages to go into them.

Improvements to the existing GUI (as well as alternatives) can be incorporated into this project.
  • Streaming real-time audio / video.
  • Enhanced security for sensitive applications.

Cross-browser testing, development, and quality assurance (incl. ease of customization and maintenance).

Streaming real-time audio / video can support a variety of applications. It has been on my mind due directly to an interest in the use of HLL in robotics. I would like to see through the "robot's eyes" via the command station GUI.

This project should provide a good cross-browser implementation of the GUI. The priority depends on user preference (or how much time I have for it if no one else is interested). The current version (demonstration) works on the most popular browsers, but development proceeds using primarily only one browser with little testing in others. In the short term, if your application does not require anywhere / any-time access, you may wish to give full support to only one browser. There are cross-browser frameworks available that could ease customization and maintenance difficulties.


Lesser General Public License (LGPL)