High Level Logic (HLL) Project

Robot Ethics Goes Mainstream

2012-01-29T14:17:00.002+01:00

With a brief commentary in The Libertarian Examiner.

WebSocket Demonstration on Microsoft Internet Explorer

2011-11-16T17:18:00.011+01:00

The main article introducing the WebSocket server demonstration did not include much information about running it on Microsoft Internet Explorer. MSIE is a bit crippled until Google frame is installed, but here I've made the process as painless as possible, I think.

First, fire up MSIE and click on this link: Step 1. That should automatically call up a window asking if you want to install Google frame. Accept terms and conditions, etc. and wait until the process completes. You'll probably end up on a page suggesting an interesting vacation spot. You can close that page and return to this one.

Then, just go to the demo page: Step 2. The demonstration should work.

Leave a comment if you try it. I only have personal access to so many computers running MSIE. Would like to know if this works for everyone. If you comment on a problem, please note the version of MSIE and operating system.

The HLL WebSocket demonstration running on MSIE.

Where do good ideas come from?

2011-11-12T16:49:00.001+01:00

Websocket Server Demonstration

2011-09-26T10:42:00.021+02:00

Subject: Pre-release demonstration for developers and others who are willing to install advanced browsers. When ready, this server will be available free to developers, with or without the HLL application software. The current version is set-up as a gateway and will include simple http processing at the time of release. (You won't have to have another server running to load web pages.)

Update (Oct. 2, 2011): Latest version of the websocket protocol (known as hybi-17) has been submitted as a proposed standard. (public notice) Technically, hybi-17 is expected to represent the first websocket standard, although there may still be revisions to the text of the written standard.

The HLL International Websocket Server is another fast, lightweight HLL component. (Running on localhost, response appears instantaneous, even with multiple “rapid-fire” requests.) I've been developing it independently so that it can act as a websocket server for all applications, whether they are HLL applications or not. HLL components will be added to make construction of any websocket application easier. HLL applications will use websockets seamlessly.

The current version is still under development. (I guess I'm just proving my sincerity with this demo.) The demonstration is like a lot of others found on the web. The web page is a bit more sophisticated. (You can download the code here, but note that it is unlikely to work unless installed on a server.) It's built for development and test, and modified as I go. But the underlying experience is that of a simple echo server. No complex applications have yet been built. I will however, hook up the robot simulation application when the server is fully integrated with HLL.

Since HLL supports distributed computing, using components anywhere in the world, the server responds to a new connection with a “Hello World!” message in Swedish: “Hallå Världen!” The default message to the echo server contains foreign characters that lie far outside the range of utf-8 (English). The server does not merely echo back the message. It processes the message first, without gumming it up; and returns its version of what it read.

The websocket standard is not yet final and I have only tested on a limited number of advanced browsers that support the most recent (i.e. proposed final) version of the websocket protocol. It works fine using Google Chrome dev-channel Chromium 14 and above and Firefox 7 and above. You should also expect to be unsuccessful when trying to connect through a proxy server. Most proxy servers have not been updated to handle websockets and will deliver an incorrect request header, causing the request to fail.

You will not get a response from the server when using browsers that do not support close to final (or final) versions of the actual websocket standard protocol or if your request runs through a proxy server (which modifies the request headers such that they are no longer compliant). The browser application will say "CONNECTION REQUESTED ...." after you click the "Open Connection" button. After a wait period it will tell you that the application is "DISCONNECTED".

Opera is currently supporting an older draft of the websocket standard that the HLL websocket server does not support. I'll hold out a bit longer to see if Opera announces an upgrade soon. Opera has done excellent work in support of the HTML5 standard generally and I want to support people who use it. The older draft version of the websocket standard will not be the final version however, so I keep expecting to hear about an Opera upgrade any time now.

I've gone so far as to set up the web page for MSIE. 8 or above to load Google's plug-in to support websockets. But I have not been willing so far to spend a few hours getting the common dhtml I've used to construct the web page working in MSIE. Maybe later. Microsoft reports that their browser will support websockets in version 10. (UPDATE: Demo on MSIE)

The demonstration server will be upgraded fairly frequently. I suspect there will be little chance that it will not be available for that reason when you try it, but it could happen. Important upgrades (such as the addition of http service) will be reported in this blog when they're ready. But because browser support for websockets is under development, I kind-of expect at least one major crash on at least one browser before it's all done. (Update: Not so much anymore. Things have been going smoothly.) I'm optimistic though. You should be too. If the web page loads a bit slowly, note that it isn't being delivered from the HLL WebSocket server.

You are invited to provide feedback. Simply add a comment under this article, or contact me by email.

If you have an appropriate web-browser, click here for the demonstration.
.
.

HLL Robot Application and SVG (Scalable Vector Graphics)

2011-08-27T11:11:00.003+02:00

I chose SVG (Scalable Vector Graphics) to implement robot movement tracking in the robot HLL browser-based GUI. This link is to the history part of an SVG Primer from W3C. Its popularity assures continued support. (Good choice Roger. -- :) {pat on back}

Excerpt:

By the end of 1999, development of SVG had begun in earnest. Within two years, six subsequent working drafts appeared. IBM and Corel each released software that exported SVG. IBM released an SVG viewer and several software initiatives released SVG drawing packages for a variety of operating systems. Since that time support and endorsement has grown. By 2005, A Google search for "SVG" returned over 3.7 million links on the WWW. Table 1 compares these results with other technologies. By February 2009, all these numbers had increased considerably (HTML itself rose almost eightfold), but SVG had risen to 11.9 million web documents moving well ahead of Fortran which had risen to 8.6 million.

Query	Number of documents found
"HTML"	1,610,000,000
"PHP"	454,000,000
"Java" (includes island)	150,000,000
"Linux"	86,400,000
"Perl"	51,600,000
"JavaScript"	49,900,000
"Unix"	35,200,000
"C++"	28,900,000
"SQL"	21,200,000
"MySQL"	20,300,000
"Pascal" (includes Blaise)	14,500,000
"Visual Basic"	8,330,000
"Fortran"	5,350,000
"SVG"	3,750,000
"COBOL"	2,630,000
"Lisp" (includes stuttering)	2,300,000
SMIL	1,600,000
"awk"	912,000
"VML"	497,000
"ALGOL"	489,000
"SNOBOL"	40,900

RoboCup 2011 Teen Size: Germany / Thailand (Final)

2011-08-19T21:23:00.003+02:00

RoboCup 2011: Adult Size Final

2011-08-19T21:18:00.003+02:00

Routine Behavior

2011-08-08T16:20:00.007+02:00

I've discussed before in my series of posts, notably in The Ghosts in My Machine: Chapter 2, that routine behavior or logical patterns are somehow difficult to accept as sophisticated enough to warrant examination in advancing machine intelligence. In my view, people can find routine logic difficult to think about and it therefore gets passed over. The uncomfortable feeling that superficially seems status oriented, might have neurological roots.

Over the years, I've become convinced that semi-unconscious or even unconscious routine behavior can be somewhat sophisticated - probably moreso than we might first imagine. It's as though our brains want to suppress thoughts about routine logic. There may be a very logical explanation for why it would - to keep us from being overwhelmed - to make our thought -> action responses more efficient. That's a classic explanation that I believe can be applied to a higher level of logic than has been associated with unconscious thought before.

Just thought I'd post what appears to me to be a related article: Could inner zombie be controlling your brain?
.

HLL to Support WebSockets

2011-08-04T15:12:00.009+02:00

The time is right. The mood is good. HLL will include its own WebSocket server. Earlier today, my test browser app. printed:

WebSocket Test

CONNECTED

With HTML5, the world takes another step in trying to catch up to me, in a very substantial way. WebSockets FINALLY provide real two-way communication between the browser and server. HTML5 will revolutionize browser based web applications. WebSockets in particular mean that all that web stuff won't need to be so point-and-clicky anymore.

The WebSocket standard is not yet finalized, but is in “final call” status. This means we should not be expecting any more radical changes to the standard, opening the door to development that won't be threatened by a constantly changing standard.

There are a few WebSocket servers that have been in development for a while, constantly upgrading to keep up with changes to the proposed standard. The Sun/Oracle glassfish project includes one, written in Java of course. Client-Server technology specialist Kaazing offers a WebSocket server free for developing and prototyping. The Google Code site offers one written in Python called pywebwocket that at the moment seems out of date.

Cutting-edge application developers have needed good stable browser implementations. This week, Google announced an upgrade to Chrome's implementation of HTML5 WebSockets. Firefox will also include an upgraded implementation in version 6. Other browsers like Opera have been putting special effort into HTML5 support. Google announced earlier a plug-in that would allow its technology to be used with other browsers, including Microsoft's Internet Explorer.

Google software engineer Takeshi Yoshino comments:

"Given that the specification is now in 'last-call' and and no further breaking changes are expected, it should now be safe to use WebSockets for production application development."

Whether developers need their own WebSocket server is an engineering decision. If you decide to build one yourself, be advised that it's not as easy as a simple socket echo server and there is no Sun/Oracle Java Trail to guide you. You'll face standards piled on standards and interesting encryptions for security. If you want to support all browsers right now, you'll need to support more than one version of the proposed standard. Once you're connected, there are issues like multiple connections to consider.

The HLL WebSocket server will continue a commitment to an independent lightweight framework for distributed applications. Application developers using HLL will be able to use WebSockets in an easy and flexible manner. Communication between HLL components is critical. Client-server technology has been there from the start. WebSockets will tie into key features, replacing older two-way communication techniques developed for earlier versions.
.

Management verses the Great Migration to Open Source Software

2011-07-19T15:33:00.011+02:00

Among the most irritating PR supports for poor management are the list of personnel “studies” purporting miracle paths to greater efficiency and lower costs. They include claims such as that recruitment and retention of good engineers are more dependent on having the right plants in the lobby than salaries and that life in cubicles promotes productive human interaction. When none of that works, then retention isn't important anyway. Might as well outsource. And it just so happens that the people behind the “studies” lease engineers as well as cubicles.

The proliferation of such ideas in the 1990s interrupted growth of a healthy sustainable technical culture that was sprouting software engineering companies at just about the right pace to provide balance between in-house IT line staff and other specialized workers. Government and government contractors were among the largest contributors to the problem as they colluded to control labor costs while maintaining their own large cubical habitats for migrating engineers. Moreover, engineers were doing well and humans tend act like humans. Seen from the inside, the emotional backlash from other professionals has been at times extreme. It was better to ship a quarter of the nation's economy to a third world country than to let “those people” live in nice houses.

What's next, letting engineers make engineering decisions? In this dark age when human resource “experts” and bean counters reigned, good engineering suffered greatly. Following their miracle plans resulted in spiraling costs and poor quality. Even the future of engineering suffered, as a great many engineers moved from company to company, project to project, without being able to stay on a consistent professional development path. As the backlash continued, experience was undervalued and many development organizations became overburdened with cheaper, less experienced engineers that took more than ten times longer to produce results that were less than a tenth as good (which also dramatically increased maintenance costs).

Where has all the innovation gone? I'm among those who have tired of Big Software selling their latest versions of 20 year old ideas as technical breakthroughs – a continuation of the great line of miracle cures for whatever ails you. It seems like too many years have passed since they should have backed up and fixed what they were already producing. Maybe now we wouldn't all be suffering so much from computer viruses and browser lock-ups and would have built the great software engineering tools that would facilitate creativity and support real business needs rather than making sloppy use of the latest bingles and bangles sometimes slightly more convenient. Since none of that really works well enough to be economically sustainable, maybe you should outsource your business operations to the new miracle on the block; “the cloud.” Never mind that there have been companies that have wanted to run your IT department since at least the days of magnetic core memory.

You might be wondering by now; what has all this to do with open source software? It's easy. Look – while the movers and shakers in the industry are busy screwing around with other things and company managers are preoccupied with the status that a nice purse and heals seems to bring, someone should be interested in producing good software. While I disagree completely that engineers are somehow less interested in being paid than everyone else (I don't care what kind of plants are in the lobby) there are thousands who would work for less at least temporarily or give of their own time to do work they can be proud of for a change and to be able to take credit for it. What's the point in spending decades developing professional knowledge and skills if you're forced to suppress all but the most menial parts? Many people actually do go into engineering with a desire to be creative and to create good things.

And why should I write this article now? You might be thinking that I'm a decade or two behind the times with my thoughts. After all, open source caught on and caught on big (except among young, naive, pimple-faced Big Software kids of course). It's become so mainstream that it is in common use and constantly growing in importance in industry. And that is the coming problem. The structure of the industry hasn't fallen back into a sustainable form dictated by market demand and a competition among professionals over who can provide the best products and services. The one thing that made the most sense was done by engineers working outside the mainstream. Where significant industry investment was involved, it was primarily to counter monopoly behavior that rendered them unable to compete in traditional ways.

Here is the part of the article where you should be interested in a solution. I know I am. I long for the days when men were real men, women were real women, small furry creatures from Alpha Centuri were real small furry creatures from Alpha Centuri, and most importantly in the context of this article – spirits were brave and engineers were real engineers. Perhaps engineers need a guild and a code of honor that they will not violate – not even for the many little queens that control most of our salaries.

Support for open-source software and projects from big industry players are at times and especially in particular instances very much appreciated no matter why they occur. Sun's support for Apache for example, has been extremely important to Internet use and the Java language and development tools are extremely important to continued innovation and development. Oracle continues some very good parts of what Sun started. Google has pushed ahead with implementation of full HTML5 support for Chrome and has made its plug-in available to drive HTML5 in other browsers. Red Hat, which started from open-source, supports a variety of open-source projects. A few years ago, Google vowed to use open-source and support for standards to return control of the overall direction of software development to consumers.

But let me suggest another path of more direct interest to the most important players; the users themselves. Not just Pam and Paul sitting in their living rooms shopping and emailing, although I'm happy to acknowledge the users that occasionally click on the PayPal button to give something back for a free software package they like. (I have done so myself.) It's the corporate users that would benefit the most from adopting open-source projects. There is in fact, a rather old idea that we can call "customer financing." When companies identify their need for software, it can benefit them greatly to individually or jointly support R&D for development of competitive products that are useful to them. It's a strategy that avoids becoming dependent on expensive fads that do not address their business needs in the best possible way.

To what extent we might be able to teach managers to think this way? What I know is that some companies are better prepared than others for such tasks. Some are themselves engineering companies, not focused on software in particular. Or companies that depend on technology to such a great extent, that they are not lacking in technical competence. These companies are most likely already routinely investing in specialized outside R&D in addition to their own internal R&D.

(To be continued ... ?)

Another perspective, time O'Reilly (1999): Ten Myths about Open Source Software

Talking to Machines

2011-06-09T12:22:00.005+02:00

NPR interviews related to human interaction with the artificial. Participants: Freedom Baird, Rollo Carpenter, Brian Christian, Caleb Chung, Dr. Robert Epstein, David Hanson, Jon Ronson, Bina Rothblatt, Martine Rothblatt and Sherry Turkle.

W3C Confirms May 2011 for HTML5 Last Call, Targets 2014 for HTML5 Standard

2011-05-27T14:51:00.000+02:00

Original Document: W3C Confirms May 2011 for HTML5 Last Call, Targets 2014 for HTML5 Standard

http://www.w3.org/ -- 14 February 2011 -- W3C today extended the charter of the HTML Working Group with clear milestones for HTML5, the cornerstone of W3C's Open Web Platform for application development. In May 2011, the Working Group will advance HTML5 to "Last Call," an invitation to communities inside and outside W3C to confirm the technical soundness of the specification. The group will then shift focus to gathering implementation experience. W3C is developing a comprehensive test suite to achieve broad interoperability for the full specification by 2014, the target date for Recommendation.

"Even as innovation continues, advancing HTML5 to Recommendation provides the entire Web ecosystem with a stable, tested, interoperable standard," said Jeff Jaffe, W3C CEO. "The decision to schedule the HTML5 Last Call for May 2011 was an important step in setting industry expectations. Today we take the next step, announcing 2014 as the target for Recommendation."

Today there are more than 50 organizations participating in the HTML Working Group, all committed to Royalty-Free licensing under the W3C Patent Policy. There are more than 400 individuals from all over the world in the group, including designers, content authors, accessibility experts, and representatives from browser vendors, authoring tool vendors, telecoms, equipment manufacturers, and other IT companies.

This is an excerpt. Complete document: W3C Confirms May 2011 for HTML5 Last Call, Targets 2014 for HTML5 Standard

Web 3.0

2011-04-29T12:43:00.001+02:00

Web 3.0 from Kate Ray on Vimeo.

HLL for Boy Scouts and Education

2011-04-13T15:19:00.000+02:00

Unique in Character

The Boy Scouts now offer a merit badge for robotics. Having prototyped HLL in a robotics project, of course my mind turned to how HLL might be useful in this setting.

HLL is still a bit raw, but already useful to more advanced developers. In the hobby league, I've posted my experience setting up a LEGO Brick to run Java so that LEGO robots can interact easily as HLL components (although there are other ways to do it). HLL can be used to set up scenarios and do any special “thinking” that's needed when running them. Due to the limited memory and processing capability of a Brick, it's most likely that the on-board Java component would do little besides accepting commands and initiating their execution.

Of course, if this is the big trick of integration, it can as easily work with anything – up to and including the most sophisticated robots for any purpose. In larger systems, even the robot's HLL processing and all its specialized components could be on-board, with another HLL installation (anywhere) for the human controllers. Other robots and other operators could all be tied together via HLL for the ultimate cooperative work, or even gaming experience.

Back to Boy Scouts and Education: I have a plan – have had from the start. Sometimes my plans are slow to evolve because I don't always get tons of money to implement them every time I write one. If you've been following this blog and / or the project, you might have noticed that it's been going a bit slowly lately. But in my view, the plan supports use of HLL from the start of the educational process through the most complicated commercial possibilities. And that does seem interesting.

In my envisioned plan, there is a version 1.x in which HLL's sophisticated technology lies beneath easy to use configuration tools. Supported by its open architectural design and open source offering, the underlying technology will still be accessible to advanced developers. Ultimately however, HLL should support rapid prototyping and scenario (mission) development by non-programmers. I would hope that in later versions, the tools and application support components, would be so powerful that all application developers would typically build their applications using only the configuration tools. But even in version 1.x, there should be many interesting possibilities for the beginner. And let's not underestimate beginners. If the tools are right, the greatest successes will come from the best ideas. How would I know who will have them?

So, let's just imagine the maximum potential for HLL. Someone uses it in the process of getting a Boy Scout merit badge. Continuing interest sparks a number of additional hobby projects during high school, each with greater sophistication and usefulness. (If we're imagining, we might as well imagine first place in a national science fair competition as well as a Siemans Westinghouse Technology Award.) During his college years, he writes a series of unique HLL application components and demonstrates their use in a for-credit undergraduate project.

He either goes on to graduate school where he writes a thesis that takes the architecture another great step, or uses his unique application components to create a new line of useful commercial robots – or both.

In any case, even if this is all – at present – just in my imagination, it does underline an important element in the unique character of HLL. I know of no robotics software tool with as much range and potential as I've described. Now, if I could just get the project moving again.

I, robot-manager

2011-04-10T13:47:00.000+02:00

Management thinkers need to ponder more about homo-robo relations

Below is a teaser from the article in The Economist.

ROBOTS have been the stuff of science fiction for so long that it is surprisingly hard to see them as the stuff of management fact. A Czech playwright, Karel Capek, gave them their name in 1920 (from the Slavonic word for “work”). An American writer, Isaac Asimov, confronted them with their most memorable dilemmas. Hollywood turned them into superheroes and supervillains. When some film critics drew up lists of Hollywood’s 50 greatest good guys and 50 greatest baddies, the only character to appear on both lists was a robot, the Terminator.

It is time for management thinkers to catch up with science-fiction writers. Robots have been doing menial jobs on production lines since the 1960s. The world already has more than 1m industrial robots. There is now an acceleration in the rates at which they are becoming both cleverer and cheaper: an explosive combination. Robots are learning to interact with the world around them. Their ability to see things is getting ever closer to that of humans, as is their capacity to ingest information and act on it. Tomorrow’s robots will increasingly take on delicate, complex tasks. And instead of being imprisoned in cages to stop them colliding with people and machines, they will be free to wander.

Read the complete article in The Economist.

.

Human enhancement technologies are nothing new: It’s what humans do

2011-04-08T16:23:00.000+02:00

Below is a "teaser" from an article by Kristi Scott posted on the Institute for Ethics and Emerging Technologies (IEET) website: Human enhancement technologies are nothing new: It’s what humans do

Phillip Brey wrote an article titled “Human Enhancement and Personal Identity” that was published as a chapter in the book New Waves in Philosophy of Technology. This is my critique of Brey’s ideas.

In his article, Brey seeks to make an argument that medicine should expand their foci from just health and therapy to include research on human enhancement effects and implementation of those enhancements. He makes his case that there should be extensive trials in medical research and policy. While I agree with him to some extent, I think that throughout the piece he has overlooked, or did not include here, human enhancement technologies (HETs) throughout history and the way they have been handled for better or worse.

Therefore, while I agree that we need to explore the social implications, I think that to strengthen Brey’s argument there should be more inclusion and acknowledgement of the past to build up the logical reasons to shift the medical foci of the present or future. Consider questions such as, have we extensively done what he is calling for with other human enhancement technologies?

For example, with the introduction of birth control, which gave us control over our reproductive capabilities, did we analyze all the possible social effects that came with this? Did we hold off on our ability to enhance our reproductive systems based on similar types of research? Why or why not? How did this effect implementation of these technologies? How could it have been done better?

This is of particular interest when he asks the same of HETs and holds them to this standard because of the change in the methodological approach to enhancements, as I will discuss. He says that, “Human enhancement should then be carefully regulated based on the outcomes of such assessments.” There is an element of control here that he thinks medicine should have in the area of human enhancements that has/is not currently done with such rigor.

Continued. Read the entire article: Human enhancement technologies are nothing new: It’s what humans do

.

Japanese Rescue Robots at Work in Japan; Global Hawk Helps in Relief Missions

2011-03-16T12:46:00.000+01:00

Complete article: Japanese Rescue Robots at Work in Japan, CRASAR on Standby

Excerpt: Japan's leading experts in rescue robotics are deploying wheeled and caterpillar-like robots to assist emergency responders in the search for survivors of the devastating earthquake and tsunami that struck the country last Friday.

Dr. Robin Murphy, director of the Center for Robot-Assisted Search and Rescue (CRASAR) at Texas A&M University, in College Station, and one of the world's top experts in rescue robotics, confirms that a team led by Satoshi Tadokoro from Tohoku University has deployed to Sendai and one led by Eiji Koyanagi from Chiba Institute of Technology's Future Robotics Technology Center has deployed to Tokyo.

Complete article: Northrop Grumman Global Hawk Flying Over Japan to Aid in Relief Missions

Excerpt: A Northrop Grumman Corp. (NOC) Global Hawk drone, based in Guam, is flying over Japan collecting data and imagery for Japanese government relief efforts, according to a U.S. military spokesman.

The drone, best known for missions over Iraq and Afghanistan, “is being used exclusively in relief efforts at the request of the Japanese government,” said the U.S. Forces- Japan spokesman, Air Force Major Joseph Macri, in an e-mail statement. It was also used over Haiti last year for broad-area surveillance.

HLL: Artificial Intelligence for Math Tutorial

2011-03-15T19:48:00.000+01:00

I've emphasized the history of thought behind HLL. Recently a retired teacher sent me a copy of a letter that I sent to her more than 20 years ago. At the time, she was working with a software company and a programmer to create a mathematics tutorial game. She had asked for my input after I mentioned A.I. as a way to improve the teaching performance of tutorial games. I provided the following: August 27, 1989. Keep the HLL General Problem Solver in mind. Not only could it provide a detailed report to the human tutor, but that same mechanism could be used to automatically alter the tutorial.

MATH TUTOR

The math tutor provides one on one instruction to the math student. The unique approach taken in the design of the software system is based on artificial intelligence techniques. These techniques are applied to continuously analyze the student's performance. Analysis is also done at a more detailed level than might usually be expected of a software system.

Continuous, detailed tracking of performance is required in order for the system to “decide” what specific skills, numbers, or operations the student is having trouble with, and how to structure tutorials or exercises to correct the difficulty. The student does not have to work through an entire set of problems, receive feedback in the form of a score, and then move up or down to a different level. Progress is encouraged by a system that continuously adapts to the student's needs, creating and presenting appropriate responses – customized to the individual needs – automatically, as the student works.

The approach helps to student progress in understanding mathematical concepts and become more competent in the application of mathematics to everyday problems. Boredom is abated by continuously keeping up with the student's abilities. Frustration is reduced by responding to problems as quickly as possible. In a sense, the use of artificial intelligence techniques allows the software to act a little more human by being more flexible, and responding more quickly to the student's needs. This explains the description of the software as a “one on one instructor.”

Ethical and Legal Aspects of Unmanned Systems. Interviews

2011-01-14T11:51:00.000+01:00

Ethical and Legal Aspects of Unmanned Systems. Interviews

Gerhard Dabringer (ed.)
Ethical and Legal Aspects of Unmanned Systems. Interviews
Austrian Ministry of Defence and Sports
Vienna 2010
ISBN: 978-3-902761-04-0

To obtain a complimentary copy write to:

Institut für Religion und Frieden
Fasangartengasse 101, Objekt VII
1130 Vienna
Austria (Europe)

or

gerhard.dabringer@mildioz.at (if you do not receive an answer please write to gdabringer@yahoo.com)

For delivery to the U.S. or other overseas destinations, please allow USD 8 for postage and handling.

For delivery within Europe, please allow EUR 6 for postage and handling.

It is also available as a pdf in our download section: http://www.irf.ac.at/index.php?option=com_docman&task=cat_view&gid=98&Itemid=18

Contributors

John Canning, Gerhard Dabringer: Ethical Challenges of Unmanned Systems
Colin Allen: Morality and Artificial Intelligence
George Bekey: Robots and Ethic
Noel Sharkey: Moral and Legal Aspects of Military Robots
Armin Krishnan: Ethical and Legal Challenges
Peter W. Singer: The Future of War
Robert Sparrow: The Ethical Challenges of Military Robots
Peter Asaro: Military Robots and Just War Theory
Jürgen Altmann: Uninhabited Systems and Arms Control
Gianmarco Veruggio, Fiorella Operto: Ethical and societal guidelines for Robotics
Ronald C. Arkin: Governing Lethal Behaviour
John P. Sullins: Aspects of Telerobotic Systems
Roger F. Gay: A Developer’s Perspective

.

A General Application Engine

2010-12-15T15:45:00.000+01:00

One of the difficulties in creating a good description of HLL is that most of the good words have already been used. Consider the following.

What is High Level Logic (HLL)?

“High Level Logic” (HLL) occupies a new position in relation to other software development tools and components. What is the highest level of general support that can be given to software development is the theoretical question that drives HLL development. Over the past 25 years, concrete and practical results have developed from this unconventional approach to envisioning the next generation of software tools.

HLL is a software framework for developing a very large number of applications, linking applications and components that have already been created, facilitating relationships between people and organizations, for interacting with people and their agents, and increasing automation of pretty much anything. In short, it does what modern applications should do; and makes an entire infrastructure easier to develop and maintain.

The opening paragraph and accompanying graphic were added to a document to clarify what HLL is; putting readers on the right track right from the start. But now suddenly, there's a contradiction. The paragraph following the graphic says that "HLL is a software framework." The graphic itself places frameworks two levels down from High Level Logic. Readers can be left wondering, which is it?

To me, this is more than just an editorial problem. It's part of a general problem in developing the language that describes computer systems and software components. Another example in HLL is the use of the term "experts." My use of the term is directly related to the definition found in English language dictionaries. I clarify by calling HLL experts, "HLL experts." For those familiar with AI, the term automatically causes one to wonder whether they're the same thing as rule-based expert system components.

I believe I can use the term framework to describe HLL. I believe it fits existing definitions and uses of the term software framework. But as the graphic shows, I think there's a need to make a distinction between HLL's position on the level-of-logic chart verses the many examples of frameworks that I'm currently familiar with. Knowing that any new terminology is one more thing to explain, I still think it's worth trying to come up with a new term.

The first thing I thought of was that HLL is an application engine. It clearly fits earlier uses of the term "engine" to describe software systems that drive applications by processing application components that have been expressed as data. (Rule-processing engine, for example.)

Ther term comes rather close to Google's App Engine and PeopleSoft's Application Engine. Google's App Engine is a platform for developing and hosting web applications in Google-managed data centers. PeopleSoft's Application engine is a batch processing system using blocks of PeopleCode and SQL.

Both the Google and the PeopleSoft "engines" are much more specialized than HLL, so to make the distinction, HLL can be called a general application engine.

What do you think?

.

Millions of tires travel billions of miles (1)

2010-12-14T20:50:00.000+01:00

When I was young, before everything was made from synthetics, we heard stories; stories about undomesticated tires living in the woods near the highway. We had seen them ourselves resting in muddy sties and dangling like monkeys in trees.

According to legend, rubber is alive. As old cars roll down the road they deposit microscopic particles of rubber on the pavement. Each particle is a larva. At the moment of birth the tiny prototires instinctively migrate toward the shoulder of the road. They join others along the way forming thin processions that in the scale of the old west would form a wagon train a thousand miles long.

When they reach the shoulder they form small colonies. As more protos arrive they become larger clusters. When large enough, they become the clutter that motorists observe as they speed by. The last stage happens only on the night of a new moon, when the treads undergo a convulsive involution and emerge as mature tires.

The life of a wild tire is tough. Those that make it to the edge of the road and adulthood face further challenges to their survival. After midnight on the darkest nights, tire harvesters cruise the roadways and load their trucks.

There is an advantage to their isolation in the woods near the highway. It’s key to their survival. No humans live there. Most people don't go there except for the occasional moment or two of relief. That's why undomesticated tires go mostly unnoticed, why modern science hasn't written about them, and why great journalists don't comment on their social and economic plight. People notice them sometimes. But they don't really see them, if you know what I mean.

At first we took the stories for just what they seemed to be, just stories. It was entertaining to hear the theory of their birth as the parent tires of our own car rolled along the road. We thought little of it of course, like ghost stories and claptrap on UFO sightings. How strange to think that some people believe in alien visitations.

But we decided to test the theory of undomesticated tires. It was an advantage living in a small town. There were so many quite country roads not far from where we lived. Many were paved which is absolutely essential to serious tire colony hunters. When we spotted a likely spot, we could stop the car and investigate, chat for a while and enjoy the sun. That led to the first of what is now our traditional Sunday drive. Three of us, now four, scouted the highway looking for ripe clusters.

The most exciting event would take place with the new moon. We began exploring three weeks early hoping to find the best spot. John is a fisherman and lectured endlessly about the effects that temperature, instinct, and even rain might have.

We discussed the possibility of danger and then chuckled it away. "Have you ever heard of anyone being mauled by a freshly constituted clan of retreads?" I've tried to remember who said that first, but always come up thinking it was a joint effort, something that emerged from the loose clutter of jovial prattle.

After about two weeks of intensive searching and note taking, Mary declared a clear winner. Out on State Highway 14 a group of clusters had formed that reminded us of a grand community of fire ants. Surely, we thought, each hill would produce a bicycle tire. The site also had the advantage of interesting terrain. We thought about sitting on the car with sandwiches and maybe a little Lone Star beer. "A real night of it," we said.

We wanted all to go perfectly and so a week later we started the evening working down a checklist. Food - check. Beer - check. Ice - stop at the convenience store on the way. We then headed for the highway for a last check of the site before picking up our supplies. It was still early and we didn't expect anything to happen until after dark.

We headed toward State Highway 14 in the mood for a party. John and Mary began building the excitement, telling stories about what we might expect that night and exaggerating the character of our find. When we reached the highway, we met with a surprise beyond all earlier expectations. Still several miles from what had been our best site was a new colony, with black rolling hills and valleys that contained enough tread for a whole sixteen-wheeler.

Mary got all excited. She kept telling me to stop and turn around so we could inspect the mounds. She sounded frustrated with me as I continued driving, eyes fixed forward like I didn't hear her. I saw something about a hundred yards ahead. About half way Mary saw it too. Then John said, "Geeeezzowie!" There was another great mass of chips, shreds, curls and treads about twice the size of the last one.

A hundred feet ahead came a third dark rolling mass. This third colony tapered off to thin low trails meandering through isolated rubber villages, then shot up again into massive towers. Mounds of varying proportion began appearing on both sides of the road with trails between each forming a continuous chain of bustling cities.

We drove on, dazed. The mass on the right side of the road faded again continuing in a smooth thin trail, not ending until it climbed to a gargantuan metropolis where the anthills of our chosen site once stood. The new moon would appear that night. Like the shores of ancient China, Greece, and Egypt, the edge of the road had become the birthplace of a great civilization.

We were numb and silent as we rolled down the highway in the car. What this meant and how it had come to be in such a short period of time was boggling my imagination. I needed to collect my thoughts.

John broke the silence. "It's midsummer's eve."

In Texas, people have long since forgotten the ancient celebrations of the seasons, having found no reason to celebrate midsummer especially. It's warm most of the year, when it's not hot. Better to rouse a sleepy air-conditioned bar or relax in the shade with an ice-cold glass of tea than to embrace the weather with any ritual.

"Frogs …" John choked. Mary and I looked for frogs on the highway but saw none. We looked at John and then at each other. He knew about midsummer's eve because of his knowledge of fishing and frogs. That didn't matter, or so we thought.

We looked back at John again. He was leaning forward with his hands over his face. Mary and I began rethinking our plan. We decided to park the car and hide in the woods behind one of the communities, somewhere we wouldn’t be detected. We decided to stick to the old plan when it came to sandwiches and beer, except for the ice. We’d have to start out with cold ones after dark.

A spot on the hillside beneath the great metropolis seemed right for our purposes. We could sneak in over the thin trail of rubber huts nearby and drop quickly into cover. So that was the plan. John never said another word, except once. He was staring down at his shoes, red-faced, shaking his head and pulling his hair. “Frogs,” he said. And then again, “Frogs.”

As we saw the last orange glow of sunset we assembled the sandwiches and beer and made our way across, hauling John along by his hand.

At home, Mary's mother looked out of the kitchen window and began to wonder. She had a special sense when it came to her children and she sensed something now. She knew it was best not to worry. She continued to gaze through the window into the back yard where Mary used to play and gazed deeper into her sixth sense. Something was going to happen.

Mary and I scouted the area stealthily, communicating in whispers and hand signals. The plateau held a small group of trees to rest our backs against as we sat and waited through the night. There were bushes hiding us but we could see around them when we wanted to. Mary pointed up the hill and snickered, “The Great Mounds of Roador.” We lost control and chuckled a bit too loudly, then both sounded “sshhh!” and broke up chuckling again. It helped ease the tension.

The location secured, base camp established, we turned our attention to the sandwiches and Lone Star beer. John was sitting quietly in a clump of bushes, staring intently in the wrong direction, down the gentlest part of the slope toward a large nearby pond.

Mary and I took our duties very seriously at first, somehow imagining that we knew what they were. We tested our skills as sentinels, sneaking a peak and darting back to cover again. The moon was bright and the sky clear. We began mapping the features of the metropolis for later comparison, only twice pointing out shadows and correcting ourselves.

Late into the second beer, I sat back and relaxed a bit and shook my head while pealing the label from the bottle. “The Great Mounds of Roador,” I mused. Mary smiled back, encouraging the light chatter.

I pitched my voice higher and became a little sing-songy. “Road decor, in the great tradition of Marshall McLuhan,” I said.

The snickers were quieter now. Mary responded faking a low voice. “Road memorabilia.”

We were on a roll and I fired back with my best imitation of Johnny Carson. “Interstate ennui.”

A question shot across Mary’s face. I shrugged my shoulders. She downed another big gulp of beer.

Sounding more philosophical she asked, “if there's rubber on the road, did the blown tire make a sound?”

By then I felt forced to go on. “Is a tire only the afterburn of the wheel?”

With that, we each took another Lone Star, tipped them in quick salute, and drank. Each swallow took us deeper into the philosophical ramifications of rubber. Around our fourth bottle (each), we were convinced that the situation was of enormous importance to the future of humanity. It was on that account that we began to formulate a daring plan.

..

All the characters in this story are fictional, and any resemblance to actual persons living or dead is purely coincidental.

All rights reserved.
Copyright © 2000-2010 Roger F. Gay.

No part of this story may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the author.

HLL on Linux

2010-12-14T19:00:00.000+01:00

The day has come. I've been developing in Windows for a long time; never seeming to get around to installing Linux on something for testing. After a disk drive on a laptop pooped out, the difficulties of getting Windows back pushed me over the edge. Ubuntu was simple to install, but since I haven't been on a Unix system for many (many, many) years, and this is my first experience with Linux, some of the rest ... well - let's just say an experienced Linux guru would have been posting this a couple of weeks ago. (Not like I dedicated 24/7 to this task though.)

Ubuntu comes with some kind of Open Java, so I eventually figured out how to uninstall that and installed Sun Java. Then I installed Apache Tomcat just in case. I haven't tried to run that yet, so I haven't tested the optional HLL browser built as part of the robot demo.

Quite frankly, I don't even know how to create a script file in Linux yet, so I typed in the java command to run HLL by hand rather than converting my Windows batch files. But sure enough, write once run anywhere - the "Hello World!" demo works. No recompile necessary.

Java Needs an Opt-Out of Static Typing

2010-12-11T16:24:00.002+01:00

I've, step-by-step, been explaining the history and character of the high level logic problem and the solution being developed in the HLL Open-Source Project. More than once, I've mentioned the enormous advantages of modern computer languages over what was available twenty-five years ago when the first few of my brain-cells became stimulated by the question. For more than one reason, I've selected Java for the implementation language. (One that I'll note is that it's currently the most popular application language on the planet, matching the intent that HLL should be a production tool, rather than an interesting curiosity.)

One great issue remains, however. Java is a statically-typed language. Why is that a problem, you might ask if you haven't yet seen it as a problem yourself? Let me take an example. I have mentioned JBoss Rules (also known as Drools) quite often in my articles. In The Ghosts in My Machine: Chapter 2 I mentioned how it overcame a critical problem in the ancient art of rule-processing.

Popular rule-based expert system tools had been built as stand-alone products to support only rule-processing, and could not be integrated with other programs and were not extensible with other programs. The JBoss rule processing system mentioned in chapter 1 deals with this problem directly. The rule-processing software is built in Java, carrying with it the characteristics of the underlying language. A rule-process can be initiated from another program and program objects can be referenced directly in rules. This allows programmers much greater flexibility to fashion their own hard-coded relationships between rules and other components in each application.

In HLL, I am about to create a similar openness in the configuration system, and that will be carried over into a simple rule-processing and planning system directly supported by the HLL core (with the option to use a more sophisticated systems such as JBoss Rules). Application developers will be able to specify their own components in XML files that the HLL processor will handle generically.

In the prototype, developers could add their own components to the core – which is very much like saying they can add whatever they want by changing the core source code. (Well, du-uh!) Because I want to maintain the concept of the core, a next sort of “bottom-uppish” evolutionary step is to predefine another package specifically for application components (that may in turn initiate other systems that HLL doesn't know about). The HLL core processing components that deal with configurable application components will have all members of the predefined “application package” imported by using a wild card (import nu.isr.hll.light.application.*;). Application developers will be able to put initiator components in the application package, and the HLL core will process them in whatever way is described in (XML) configuration files.

One HLL unit can also contact another HLL unit with a request to have one of its application components executed, with results returned. But I dream other dreams. I would like to build dynamic HLL applications that can process components that were not defined at compile-time. I'd even like to be able to fetch objects from somewhere out in the WWW that a particular HLL unit has never heard of and run them locally. What I'd like is a LoadUndefinedClass class with methods for calling methods and accessing public fields.

And really, I can almost do this with generics. I can almost build the LoadUndefinedClass class using reflection. Almost isn't good enough, of course. No matter what trick I play on the compiler, the run-time engine is going to throw an error if there's no predefined class for it to refer to.

So, what's stopping us from getting a LoadUndefinedClass class? Purity of the language? Fear that Java programmers might write programs that don't work? Come-on!!!

UPDATE (Sept. 6, 2011) InvokeDynamic class : New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine
.

Regarding Human Intelligence and Decision Strategy

2010-11-13T23:54:00.001+01:00

When Will We Have Artificial Intelligence?

2010-11-13T13:33:00.001+01:00

When are we going to have AI, one survey asks? It's a question relevant to HLL because so much of the thought behind the HLL design comes from the history of AI research and current technology that has come from AI research. The answer to the question when, with reference to HLL, is now. (Or at least as soon as version 1.0 is ready.) And that's no reason to get worried. As the description of HLL claims, you don't even need a high-powered computer science background to build applications with it – just some (OK, but at least reasonably good would be nice) programming knowledge.

The AI question is actually a bit tricky. It really depends on what you mean by AI. Way back in the cave computer days when I was first introduced to the subject, artificial intelligence research was defined as trying to get computers to do things that humans currently do better. Applying that definition, it seems as though the answer may be never. As soon as computers can do something at least as well or better than humans, it's no longer the subject of AI research. Object oriented programming is an example of something that came from AI research. Now a mainstream programming paradigm, many people don't associate it with AI at all.

The variety of ways of thinking about AI is also why some researchers predict AI won't exist far into the future while others (like me) are much more optimistic. People who answer the question may have something very specific in mind and think it will be a long time before it will become reality. You can also think about all the things computers do now – such as mathematical calculation – and make a case that AI already exists (something humans and computers both do, and computers do well). The great variation in predictions on when AI will come, has to do with both the particular sets of things that guessers think need to be done before “AI exists” and how optimistic or pessimistic they are about doing them; while basic research always looks ahead.

You've probably heard that human intelligence is linked to the fact that we have opposable thumbs and other peculiar physical characteristics like standing upright and walking erect. Researchers recognize that in living creatures, intelligence and the characteristics of their physical bodies are linked, which makes robotics fertile ground for AI. (related article) Not all researchers focus exclusively on human intelligence and capabilities however. Some of the most interesting advances have come from looking for ways to mimic the behavior of other creatures, from insects and snakes to mules. The intelligence of a lower species is still intelligence, and some of the developments that come from mimicking their behavior can be applied in layers when mimicking behavior in higher ones.

Where does HLL actually fit in? Twenty-five years ago, when I was first thinking about the “high level logic” problem, I thought of it as a subject for advanced research. Since then, computer languages have advanced considerably and in ways directly matching the requirements of HLL. Strong networking support is a must, which has come from focus on Internet applications. Relatively recent additions to Java (which I've used to build HLL), such as strong support for generics and reflection have transformed some of the challenging bits into stuff that's just pretty cool.(Once again, application developers are not required to have expertise in these techniques – although it's quite alright if they do.)

To some extent, even the concept has been encroached upon (so to speak). The short descriptions of HLL have called it an “agent system” and I worry at times that it will be perceived as nothing more than an alternative to existing agent systems (which I won't mind so much if it becomes a popular one). The overall HLL concept is the thing that remains new, and while fitting into the current modern software development world well, I still think it has potential as a tool in advanced AI research and application development.

HLL development has been proceeding as an ordinary software development project. With use of modern software technology and twenty-five years of thought behind it, not much experimentation is now required; less than the ordinary amount for development of a complex software system, because even details and how it all fits together have previously been thought about. And all that is why it (version 1.0) will be a powerful, light-weight system that is easy to use.

So, is it AI? When people are using it regularly to build applications, I certainly hope it's thought of as AI just as much as rule-processing or object-oriented programming and all the other things that have come from thoughts on developing AI; and yet, fully accepted and integrated into mainstream applications development. Why not integrate HLL support directly into programming languages?

For most people, thoughts on what AI is continuously focus on the future. With twenty-five years of history, I think I've earned the right to use a tired old cliche to end this note with a response. As far as HLL is concerned, the future is now. (Finally!)

Another view: How Long Till Human-Level AI? What Do the Experts Say?
(AGI = Artificial General Intelligence): “I believe the development of AGIs to be more of a tool and evolutionary problem than simply a funding problem. AGIs will be built upon tools that have been developed from previous tools.”

.

HLL Factory

2010-11-10T12:18:00.000+01:00

It occurs to me that HLL application units should be easy to integrate with other types of application components. The current design allows any sort of application component to be integrated into the HLL logic - since HLL was conceived as the "high level" logic for applications. Interaction between HLL units (an agent approach) is fundamental to the design.

But, some application builders may want to incorporate HLL unit technology within other types of programs. I haven't thought of a reference or example application yet, but it seems kind of obvious conceptually. There may be an HLL infrastructure operating already. An application designed in some other way may want to interact with it, with either fixed or variable specifications for its exact purpose.

In such cases, an application may want to make use of an HLL Factory to construct an HLL unit on the fly that will interact with other HLL units just as one of them. The fact that HLL pushes the high level application logic specification into data would make it easy to create or modify the specification on the fly.

Creating a good HLL Factory set-up would take some thought in design, but is quite doable. So much so that I expect, as the concept of an HLL Factory matures (along with completing more of the code to version 1.0), it should surely be done.

I have added HLL Factory to the issues list, but not as a high priority. Since HLL is not version 1.0 yet (but getting closer every day - and I'll remind everyone that is it already possible to build applications) - and there is no existing HLL infrastructure anywhere out there (although there are agent systems running), I sense no great demand right now for dynamics to interact with an existing HLL infrastructure. The day will come however ...

The Ghosts in My Machine, Chapter 3

2010-11-07T17:35:00.001+01:00

Chapter 1
Chapter 2

Prepare yourself for a surprise ending. Do that now to avoid confusion later.

Around 1990, I met with an industrial engineering professor who had been working for years with artificial intelligence technology. We had a long chat about the possibility of completely automated factories. This was still a decade before frequent online purchasing and customer management systems. But it seemed reasonable to contemplate a future in which everything from initial customer contact, sales, accounting, instructions to the factory floor, robotic manufacturing on demand, packaging, right out to the shipping dock would be fully automated.

Even if you've never considered designing such a system and are unfamiliar with any such work in that direction, it isn't long before the thought occurs that such a system should be broken up into departments and operational segments. Each operation has its own specialized “knowledge” and processing to contend with, and it seems likely that interfaces between operational segments might need only handle common data exchanges. Jumping ahead, one might consider that an agent system could provide loose coupling between operational components as well as the possibility of moving pieces around from time to time for special types of interdepartmental operations.

It isn't a big jump to consider that breaking the application into “departments” is at least in part, an exercise in modeling the framework of the human organization that complete factory automation would replace. The fact that this model already exists, that it's completely common, may be the most important reason that the idea of breaking the software design up this way is so obvious. Compartmentalization is not a concept invented by computer scientists. Humans do it all the time, and have been doing it for ages. If we're going to think more about obvious common ideas, then this idea easily qualifies on that ground.

The concept of an “object” was also not invented by computer scientists. (I merely need to open this idea so that I can be flexible about its use without confusing anyone – i.e. a fair warning against thinking “simply” about common current day object oriented programming structures and techniques.) Objects exist in the world around us and we can ourselves be described as objects and operate as such. They have characteristics and some have capabilities. They interact in various ways and react in various ways to interaction. Complex (compound) objects can be composed of simpler objects; the whole sometimes being equal to more than the simple sum of its parts. The concept of an object or “entity” (in certain modeling models) is fundamental and useful in describing pretty much everything – solid ground for high level logic.

Dwelling on what at this point may seem quite obvious; we're – very generally speaking – looking to design a set of organized objects. One way or another the individuals and / or the organization will be structured to carry out tasks and solve problems, answer questions and whatever. The important distinction here is that the intent is to build a general processing engine; not a specific application that could be described exactly the same way – as a set of organized objects. The expected practical effect, if successful, is that some portion of “common” logic in a wide range of applications can be moved into the general processing engine, where it does not need to be repeatedly rebuilt in the application phase.

Another important distinction is that the High Level Logic Project attempts to do this by searching for “high level logic” rather than by “bottom-up” development. This is why I've chosen such a long-winded approach to introducing HLL. Ideas that are common and fundamental are useful and enduring. They don't need to be derived - "bottom-up" - from the most recent set of application programming frustrations.

So let's take the next step in thinking about departments in human organizations. There are various kinds of organizations, but I didn't mind leaning on my familiarity with the typical American corporate structure, and particularly with project oriented groups. Projects begin by defining a task or problem and end with a specified result. There is at least a rough analogy between this process and the general problem solver outlined in chapter 2. Project organizations are made up of individual people with specialized roles and responsibilities that form sometimes simple and sometimes complex task hierarchies.

Certainly our task cannot be to describe the individual characteristics and operations of all existing human organizations, or even of one large organization like IBM. Organizations change, and a detailed description of any specific organization is not a general model. A general high level logic engine needs entities that can be characterized by application developers or another process. The system for describing organizations needs to be easily extended by adding, defining, and organizing entities. The relationship between entities needs to be “loosely coupled” so that they may move around, help others by use of their special knowledge and capabilities, and form sub-groups to perform tasks as needed.

There is a difference between general and generic. The description above remains pretty generic. Certainly, organizations as “organized objects” seems so. It is possible to add more specifics to a general model (applying to all or most members of a category or group), or one postulated as being general (not specialized or limited to one class of things) without fear of limiting an application developer's creativity and adaptations to meet specific requirements. Allowing developers (and other processes) to customize, add, delete, define, redefine, and organize – i.e. to completely control the specific definition of the generic engine's application does that. (It's something like bringing entity-relationship diagrams to life.)

But still, it plagued me that there is apparently at least a rough analogy between the workings of a project organization and the general problem solver outlined in chapter 2. What minimal organization could assure complex task completion and be highly relevant to a wide range of software applications?

I had spent years working in project groups, and it was that experience that I most thought about when making the analogy. Generalizing a bit, the organization started at the top with an executive (like a VP of Engineering), who reigned over one or more (project) managers, who organized and managed the activities of groups of experts (in most of my personal experience – engineers). In the human world, such a simple three-layered organization has been responsible for carrying out a very large range of very simple to extremely complex tasks.

It was time to describe the characteristics and capabilities needed for a basic three-layer organization model, one that made sense generally, and would be highly relevant to a wide range of software applications. That part turned out to be not particularly difficult, and led to detailed design requirements and specifications (chapter 4, some of which are already hinted at in this chapter).

Minimal description of the three-layer HLL general organization model:

Executive(s): Interacts with external and internal “interests” to formulate, offer, accept, or reject proposals or demands. Decides whether or not to make commitments. Is concerned about the general allocation of resources within an area of responsibility. Assigns complex tasks to managers.

Manager(s): Plan an implement tasks that have been assigned to them, using available resources.

Expert(s): Carry out work details for which specialized knowledge and skills are needed, often in cooperation with other members of a group.

Very clean model so far, perfectly obvious in many respects. On the good side, it could easily be taken as a generalization of many processes including many, many software applications. Then I felt a great discomfort with the human organizational analogy. I and a great many others often feel discomfort with being a cog in the wheel of an organization. It's not quite natural. Something is wrong. (Here comes the surprise ending.)

Don't we all, individually, commonly carry out tasks requiring all three levels described above in our daily lives? What's the difference between a large distributed organization and an individual (in the context of this discussion) other than that large distributed organizations can get a lot more done in a specific amount of time? There isn't necessarily a difference between the structure and function of a multi-person organization (model) and an individual.

A friend of mine who happens to be a cook recently asked me to explain that to him. A cook, interacts with the outside world (outside the kitchen); a good example being the communication of an order from a customer via a waiter (an agent). The cook may accept or reject the order. (If for example, the order is not complete or the kitchen has run out of an ingredient required to make a dish.) If the order is accepted, he commits to the task, then assembles resources (ingredients, cooking implements) according to a plan (complete dish specification and recipes). He then prepares the food and the dish, using specialized knowledge and skills.

The fundamental high level logic had not collapsed, but it became apparent that application developers should be provided with the greatest flexibility in interpreting, mixing and applying its pieces. Large organizations like IBM are human creations, sometimes necessarily physically distributed, that can accomplish more in a particular amount of time. Otherwise (in the context of this discussion) nothing more than a reflection of ourselves and the way we – necessarily – accomplish tasks that require a higher level of intelligence.

From the High Level Logic (HLL) Open Source Project blog.

XML Configuration Processing – Progress Report

2010-11-04T13:20:00.000+01:00

The importance of issue #1. Configuration Files and Processing should not be underestimated. The configuration system is used to attach application components to the generic HLL processing system. It makes sense to create a powerful configuration system that is easy for application developers to use and quite flexible so that it does not impede creative development. And when the project begins building tools to further simplify the development process, they will (in part) simplify the construction of configuration files that, in effect, define HLL applications. A powerful configuration processing system will facilitate powerful but easy to use tools. (For programmers, the process is already easy even without the tools.)

In addition, what is becoming a sophisticated configuration processing system will be extended to process plans (management layer) and then further extended to build a simple rule-processing system. (Sophisticated rule-processing can be handled by existing sophisticated rule-processing systems.) All of these features require processing XML files in sophisticated ways. (Including things like handling class and method specifications generically, building things on the fly with reflection techniques, and constructing and modifying the XML files themselves on the fly.)

My progress on developing the configuration system has been interrupted by other demands; just the sort of thing that one must expect in this kind of project. I was, for example, invited to present the HLL project to a group of about 150 IT professionals in Stockholm, which I was quite happy to do. And if you've been following this blog, you know I've spent some time drafting commentary on HLL in a way that I hope provides a meaningful introduction. (If you have been following, please note that I expect chapters in The Ghosts in My Machine to become less historical / philosophical and more concrete and technical, eventually explaining the design and how to build applications.)

The prototype already had a working configuration system. It would not have been a working prototype without one. But it was much less flexible than it should be in version 1.0. In order to get the prototype up and running quickly, I had done things like hard-coding configuration file names and wrote custom handlers for each file. It was good enough for proof-of-concept, but not what I'd call “real code.”

Back to work, progress has been good.

Configuration files and handlers are now specified in a master configuration file which is read and processed. It will also be quite simple to add an option to specify the master file as a command line argument. (So simple, that I may do that before committing the code.)

The HLL predefined configuration files are optionally checked against schemas. This option will be available for configuration files created by application developers as well.

I've decided to stop working on configuration for the moment. It should not take too long to deal with issue #2. FIPA Compliance , and I hope to include this, along with the current configuration file handling improvements in a new source code commit by the end of the week (i.e. tomorrow). Then I think it would be an extremely good idea to update the simple demonstration binary download and tutorial on application development.

It seems to me that moving on directly to work on plan processing before returning to configuration would be a good idea. It is intended that plan processing should be built on the processing capabilities of the configuration system. Work on planning first, allows me to simply paint on a fresh pallet with modified code from the configuration system to get the result that I want – assuring that it works for planning. Then I can return to configuration and simply apply the relevant new bits for the final upgrade.

Artificial Intelligence

2010-11-02T21:50:00.000+01:00

The Ghosts in My Machine: Chapter 2

2010-11-01T18:02:00.001+01:00

Link to Chapter 1

I understood the differences between what application developers wanted to do and what the “artificial intelligence” technology of the late 1980s supported. They were not the sort of differences that one might use to contract to update a software application. What had been, in effect, a broad survey of application needs resulted in a snap-shot of a more basic set of technical requirements. This snap-shot taught me much about the path of development of software technology generally, decades into the future.

Much of that future would evolve with or without me, as developers pushed to realize their dreams and the more basic technology developers – involved in computer languages for example – responded to demand by building their tools bottom-up. But I had become obsessed with what initially seemed like an unapproachable problem – one that might raise a slight giggle around a lunch table. As computer languages and tools evolve to higher and higher levels - “bottom-up” - where will they eventually reach? Where's the top? Even if the question is unanswerable, the more I thought about it, the more I found value in the thinking.

There were also two general observations about people that allowed me to consider that my ideas would be at least somewhat unique. The first is that people often tend to mistake common, ordinary ideas as trivial. In fact, the opposite is more likely true. If something is common, it is likely important, or at least extremely useful. Simply cast the thought in different words such as the basic economic measurements of supply and demand, for example, and more people will agree. Something becomes common in any culture because there is a demand for it. The other was that, at the time, it was rather difficult to get many experts to think about the difference between the idea of a machine doing something on its own, and what they were doing. Many programmers scoffed at the idea of specialized rule-processing engines, because they could already use if-then statements in their own programs. Management consultants and statisticians could not see a reason for interest in theoretical math engines that could build their own models and solve problems because statistical packages already allowed them to select from a variety of basic mathematical forms and discover a set of parameter values that produced a “best fit.”

Even as I write today, a quarter century after my thoughts on “high level logic” began, I wonder if I will hit the same snags as I try to drum up interest. That software tools evolve to support higher level functionality is quite commonly understood. And then there is the trigger that set my search in motion. Every systematic analyst (whether professional or not) knows that it is important to define and understand a problem before expending much effort to solve it. They've done it themselves, over and over again, many times.

Let me proceed then to something else that was already common before I began my quest. Not only is it not my invention, but if I recall correctly, it was first introduced to me in grade-school. This is certainly the kind of thing that could potentially send readers to another page, thinking that it is proof that I have nothing new to say. A general problem solving algorithm has been described, that begins with defining the problem. I trust that the process will be recognized by a great many people.

1. Define the Problem or Task
2. Assemble Detailed Information
3. Perform Analysis
4. Identify Alternatives
5. Recommend Solutions

This is a description of an extremely general process; and that certainly is a characteristic sought after in the search for high level logic. Not only do professionals systematically follow such a process in dealing with complex problems and issues, but it is difficult to think of any, even slightly complex process that cannot be cast in its mold. If I, for example, feel hungry at 10:30 at night while watching television, I will already have defined the problem. I am hungry. I will then proceed to the kitchen to assemble information. Looking into the fridge, I will see what is available. I will analyze that information, considering how I might use the ingredients to make something to eat. That will produce a set of alternatives, from which I will choose. (“Recommend Solutions” is a phrase chosen in context. I had been considering the development of better “expert systems.”)

Having given a good bit of thought to rule-based expert system technology, it was easy to see that the above general problem solving algorithm could be used as the design of a software engine, which I describe below. Once I was certain that the idea was concrete and feasible to implement, I began thinking of it as the rule-processing equivalent of “structured programming” - i.e. the addition of for, while, and if-then statements into “high level” languages and functions replacing goto statements. Not miracles, but an extremely useful advance in computer technology.

Rule-based expert systems had a great deal of success in focused diagnostics, which meant no new investigation was needed to see that the same approach could be used in the first step of the general problem solving algorithm. To fill things out however, the process needed to proceed to step 2 rather than too quickly toward the last step – making recommendations. The concept of “objects” (although not necessarily their implementation in object oriented programming languages) easily suggested the transition from step 1 to step 2. Each meaningful “entity” involved in the problem definition would have associated characteristics and resources. Resources can include sources of information, such as databases or flat files. Where circumstantial information is needed in each run, either updated information was needed from these information sources, or the user would be asked.

The need to integrate step 3 into the process was one of the best known problems at the time. The age of open systems development had not yet arrived. Popular rule-based expert system tools had been built as stand-alone products to support only rule-processing, and could not be integrated with other programs and were not extensible with other programs. The JBoss rule processing system mentioned in chapter 1 deals with this problem directly. The rule-processing software is built in Java, carrying with it the characteristics of the underlying language. A rule-process can be initiated from another program and program objects can be referenced directly in rules. This allows programmers much greater flexibility to fashion their own hard-coded relationships between rules and other components in each application.

In a more general approach, these relationships should be discovered automatically in the resources associated with the entities defined for the problem definition stage, the same mechanism used in support of the second step. Then, applications can change merely by changing the data associated with the application, just as is done in general rule-processing and expert systems. The program itself, a general processing engine, would not need to be changed, either when updating an application, or building entirely new applications.

In the final two steps, I primarily fell back on rule-processing and rule-based expert systems concepts again, but operating on the information accumulated from the first three steps.

Another thought occurred to me that fit the idea of artificial intelligence research perfectly. It might make my imagination seem slightly flexible, but I saw a one-to-one relationship between the general problem solving algorithm and the structure of good presentations I had learned in a high school speech course. (I was in fact considering just how general the above algorithm was, and how broadly it could be applied. There seemed no end to the possibilities, when one started replacing words like “problem” while maintaining the same processing logic.)

Monroe's motivated sequence

The basic speech structure

A. Attention step
B. Need step
C. Satisfaction step
D. Visualization step
E. Action step
A. Introduction

B. Body of the speech

C. Conclusion

It occurs to me now, so many years after the fact, that it is too difficult to recall all the thoughts that brought the general problem solving process into correspondence with the idea of presentations. I am not a numerologist, but cannot do better at this moment than to mention that both processes have five steps. After considering several examples, I became convinced that by adding well developed descriptive text as additional resource elements associated with problem entities, a program could automatically generate well-formulated reports in five sections; complete with data gathered and derived through each step in the problem solving process. The reports I envisioned could be as good as, if not better, than those produced by many human consultants.

This was interesting, but obviously not the top of the logic hierarchy. Many different problems arise each day – many different tasks to take care of. It cannot be said that solving one or many represents the top of the human activities management process. Somewhere around 1990, I met with an industrial engineering professor who had been interested in artificial intelligence applications for years. We had a long chat about the possibility of completely automated factories. This was still a decade before frequent online purchasing and customer management systems. But it seemed reasonable to contemplate a future in which everything from initial customer contact, sales, accounting, instructions to the factory floor, robotic manufacturing on demand, packaging, right out to the shipping dock would be fully automated.

Again – not a numerologist – but note that a more general description of the presentation process is given in just 3 parts. Coincidentally, that is the number of elements that I think necessary in the next step in high level logic – the subject of chapter 3.

The Ghosts in My Machine: Chapter 1

2010-10-29T14:23:00.001+02:00

As a young man, when I enjoyed idle time and my daydreams tended to wander in strange directions, I found myself considering a rather unimaginative question. As computer languages and tools have evolved to higher and higher levels - “bottom-up” - where will they eventually reach? Where's the top?

To put this contemplation in perspective, the year was 1985. The computer under my desk was a first generation Texas Instruments PC with two floppy disk drives. Ethernet cables were being strung through our offices to network our computers for the first time, allowing messages to stream around the building at the blistering rate of up to one thousand bits per second. The idea of using personal computers to access a wide array of interesting information, to project presentations stored on them, and to somehow integrate them into “teleconferencing” were subjects of advanced industrial research and design. The Apple Macintosh was recent news. Yellow power ties were “in.” On the cutting-edge, people debated whether “object oriented programming” would ever really catch on.

All past generations are perceived as naive; aslant comfort as I tell this story now. For I became somewhat obsessed with that odd and uninspiring question. Where is the top? As unanswerable as it seemed, the more I thought about it, the more I found value in the thinking.

The question did not occur to me entirely at random. The group that employed me at the time was particularly interested in “rule-based expert systems,” a well-developed form of rule-processing that was, at the time, thought of as artificial intelligence technology.

(RULE-1: (IF: <user-1> ((think)) that's <naive{in hindsight}>)
(THEN: ((wait)) 'till <user-1> ((READ-CONTINUE))))

In historical context, it was actually a much more interesting time than empty hindsight might suggest. There was focus on expanding the common roles of computers in data fetching and number crunching to include more powerful forms of symbolic processing. Artificial intelligence research was defined as trying to get machines to do what at the moment, people do better. It was a time to think basic thoughts and explore new directions. And then there was the hype.

The idea of artificial intelligence fascinates. Writers in the popular press could not resist the temptation to contemplate fantastic futures brought about by its commercialization, as if the full blossoming of machine intelligence was only months away. It happens in every generation. Today, in the light of well-funded advances in robotics, we worry too much about machines becoming in some way more intelligent than people and using that intelligence to take over the world – a theme perhaps not yet entirely exhausted in science fiction. There are the annual singularity conferences that include discussion on uploading your mind to a machine so that the ghost of your thought patterns can survive your death. (Sadly, it seems that not everyone will have use of a robot body like Zoe Graystone.) And then one can well wonder about human-machine marriage law once robots have become sufficiently advanced to serve as satisfactory sex mates and companions. (But can it cook?)

In the mid-1980s, perhaps we were too naive to connect such dark and mystical thoughts to our first generation personal computers. There simply wasn't much personality in “C:> dir /P” displayed on a monochrome screen. Rule-processing systems were just part of the parade of options opening up a new world of intelligent automation. But with them, complex business issues would be resolved at the press of a button, quality medical diagnosis and agricultural advice would be delivered to third world countries on floppy disks, the art and skill in untold areas of human endeavor could be translated into computer programs by “knowledge engineers.” As machines began turning out the best advice human experience and machine computation could deliver, the quality of life could improve everywhere and the world would become a better place.

The mood was upbeat. The excitement palpable. Researchers in all fields began competing for new funding to apply the technology in their own fields. Their ideas were wonderful, their plans divine. There was seemingly no end to the possibilities. I had a front row seat to much of it. My job involved presentations and discussions at universities and national laboratories throughout the country. I saw the wonder and curiosity in their faces as the software concepts were first introduced and the thrill of starting new projects with great promise. I exchanged friendly comments and jokes with them as their work proceeded through the first interesting efforts and did my best to respond to the thoughtful and carefully stated questions as problems arose. And then, in what in the vastness of history may seem like nothing more than a split second after the whole thing began, I felt their frustration turning to anger. For most of them, it turned out, rules were not enough.

Leading artificial intelligence researchers of the day were scrambling to make a go of their own commercial enterprises. There was evidence of bottom-up evolution in complexity. The idea that object oriented programming provided an opportunity to effectively model concrete objects and abstract ideas related to the real world was applied in frameworks to allow logical relationships between objects. “Frames” also provided a way to break rule systems into sub-systems.

But these few steps were not enough to keep the artificial intelligence revolution promised by excitable journalist going. It had been an interesting top-down experiment led by a few researchers whose bottom-up developments did not go far enough, fast enough. Too many visionary application builders from outside of engineering were failing. Overly heightened expectations caused the reputation of the whole of the artificial intelligence idea to suffer greatly. It didn't matter that someone somewhere might have been thinking about the next solution. Funding agencies and investors lost interest.

The change in mood turned my role in the experiment into something like a traveling complaint department. I tried, once or twice, to remind those who had used our technology that the scope and limitations of our products had been explained. In some cases, the conversations were merely new versions of old chats in which I had directly stated that significant parts of their design were not supported by our products and would be difficult to implement. But the disappointment was as palpable as the excitement had been before. Their visions had been clear, their ideas wonderful, their plans divine. It must be possible to do what they wanted to do. Something was to blame.

The groups that had tried to implement sophisticated intelligent applications cut across a nice spectrum of academic disciplines and interests. This led to what initially seemed a wide range of application related problems. But as I listened to more stories, some parts of their problems began to sound similar. A pattern emerged. Underlying the diversity of application interests laid a concrete set of basic definable technical problems.

Our company had a particularly good working relationship with one of the leading researchers, so I sent an email describing the problems. The list became part of a conference presentation somewhere. But there was no way that I could stop thinking about them. In my mind, the crash of artificial intelligence technology in the 1980s was transforming itself from a great disappointment to a unique opportunity. I had discovered a clear definition of the difference between what practical application builders wanted to do and what the technology of the day had to offer.

In the normal course of events, I might have worked on designs that addressed each of the individual problems on the list, with each solution having a potential for commercial application. This is the way progress is normally created - “bottom-up.” But the circumstances triggered more philosophical thoughts. The combination of the overly optimistic expectations of funding agencies and application builders demonstrated that bottom-up is not always good enough. Had my degrees been in management or marketing, I would probably have simply noted it as a classic error. But I am an engineer. Problems are meant to be solved and it is somehow not in my nature to be able to turn by brain off to them.

It was in this stream of events that my mind became fixed on that naive and rather unimaginative question. If technology developers had anticipated the needs of application builders and moved directly toward satisfying those needs, the failure would not have been imminent, as in hindsight, it clearly was. But this was cutting edge stuff. How would anyone know what they had not yet discovered through experimentation and experience – trial and error – yet another problem identification step that could lead to more progress?

Something else began to play in my mind. It had already become part of my life's wisdom to recognize that seemingly simple things, the ideas and processes that we mostly take for granted because they are common and therefore presumed uninteresting, are often the most profound. On many occasions I have seen sophisticated ideas initially fail, and then slowly evolve until the most basic logical considerations forced compliance. Then it worked.

Involvement in artificial intelligence naturally involves thinking about intelligence generally, about our own intelligence, and our own thought processes. If artificial intelligence is working on things that at the moment, humans do better than machines, we think about what we do, and how we do them. My brain had not turned off this self-reflection either. Something had triggered my concrete confidence that I could solve problems that had not previously been solved – and to know that the solutions would be useful. I have mentioned it. Is it something that you, dear reader, have taken for granted because it is common and therefore uninteresting? Or do you know to what I refer?

There are pieces of generic processes; simple, common, so ordinary as to be overlooked. A common thought, that systematic problem solving begins with defining the problem, sent me to the mall to find a laboratory notebook. The jottings, ideas, diagrams and pseudo-code represented my obsession with breaking free of the bottom-up approach to development and progress. My eyes turned from the problems immediately surrounding me and slowly upward against a seemingly endless empty space. My search for “high level logic” had begun.

Footnote to chapter 1: The specific “failure” of artificial intelligence technology presented in this article has to do with its presentation and timing, along with overly enthusiastic expectations over a relatively short period. (related article) As techies around the world know, object oriented programming became a mainstream technique supported by extremely popular programming languages. Advanced rule-processing is an added tool in such things as database systems and embedded in a wide range of “smart” products. The ability of software to process “business rules”is commonly marketed. One open-source rule-processing system (Drools) became so popular that it's now included in the JBoss Enterprise Platform and there is a standard set of interfaces for rule processing components in the Java programming language. Although I had not seen “problem definition” as a framework component in a larger generalized process, the importance of problem identification had been pointed out in specifics, particularly with the development of diagnostic systems.

Link to Chapter 2.

LEGO Mindstorms NXT Robots (leJOS)

2010-10-21T11:47:00.000+02:00

Being oriented to work on tools and middleware, I allow myself to get enthusiastic when software reaches the stage that it makes something else relatively easy to do. So, I feel no regret posting this comment in advance of a working demonstration. (Something does actually work – read on!)

Creation of a robotics demo for HLL has to this point proceeded with a simple robot simulation. Movement and positions were nothing but numbers fed from the simulation and translated in the browser-based GUI to a colorful circle moving around through two rooms, which were nothing more than a 2D outline. (Only tested on Firefox, so if you're not using Firefox, you might not see the first (dynamic) image of the "robot" moving through the rooms below.)

Your browser does not support iframes.

The High Level Logic (HLL) software system deals with what the name implies - high level logic. It's designed to provide and support high level logic for all kinds of applications. So, motor control and sensor feedback really has nothing to do with working on the HLL core system. Robotics is a good and fun application to work with; and certainly to the point back when a robotics research project was paying for the work.

For 2-3 years now, I've had a LEGO Mindstorms NXT kit that didn't get any attention past trying out Microsoft's (at the time new) Robotics Studio. A friend of mine recently decided not to let it go to waste, and built the first robot by following the instructions in the booklet that came with it.

I've switched computers since last installing the Mindstorms software. The copy that came with the kit did not contemplate 64 bit architecture, so the simple installation from CD didn't work. After googling around a bit, I discovered a good set of instructions to get the job done. (Getting to Grips with Installing, Updating and Programming LEGO Mindstorms Kits.)

Software that came with the kit successfully installed, I checked to see if everything was working. Check, check, check. Now to change everything. What I really want is to create some smart high level logic using HLL and send commands from there to the robot through “experts.”

The focus of my work is on HLL, so I'm not interested (well, maybe I'm interested and it's more a question of time and keeping my efforts focused) in working out all the Bluetooth communication and NXT control code myself. Wouldn't it be nice if someone who had already developed that technology had made it available. And someone did. (Actually, I knew that.)

I installed leJOS NXJ, which includes replacing the firmware on the LEGO Mindstorms NXT brick. Now it's ready to interact with Java programs on my computer – well, not quite.

The installed software for leJOS hadn't contemplated 64 bit architecture either. When trying to run the first sample program, I got error messages telling me it couldn't find libraries like “intelbth_x64”. Luckily, leJOS project contributors did something about that this year and the problem was easy to fix (by replacing the ...\leJOS NXJ\3rdparty\lib\bluecove.jar file that came with the downloaded installation with the latest snapshot. Check here to see if that's still the most recent if you have this problem.)

Magnifique! The first sample program ran. It didn't matter that it only passed a Java program that plays a tune to the brick (which immediately played the tune). This is progress.

So, now you also have an accurate status report on the state of getting a LEGO Mindstorms NXT robot to run with HLL. I haven't hooked it up yet. I haven't yet even delved into the samples that come closer to what I want. But the basics are working, and that's an excellent start.

The Prototype is Dead!

2010-10-16T20:03:00.000+02:00

After getting back to concentrating on the core code for a little while, I'm happy to report that the HLL prototype is officially dead. The age of "clean up" has ended and everything ahead will have to do with improvement and expanding functionality.

The final throw may seem like a small thing. I had defined "trace" and "monitor" variables in every class I wanted to kick out program trace information to stdout and to the GUI. Pretty nice to see trace information in the browser while developing. It let me see anything I wanted to see in what was basically an ongoing end-to-end test while I worked. I also didn't need to go back and forth between the GUI and console to see what was going on. (For more detail on the browser-based GUI, refer to posts like this one.)

But, while focusing on everything else while building the prototype, I had set the values independently in each class. It never seemed a pressing issue while prototyping, because I would either focus on core development, or on GUI development for lengthy periods of time. So, the inconvenience of changing the values in each class never pushed hard enough against other pressing issues.

So, now there's a new config file called manage_cfg.xml, that's meant to be kindof a catch-all for this sort of thing. And when everyone else wants to switch between the two, they just set the values to true or false in the config file. One place - real quick - that's all there is to it.

Need more reason to understand my celebratory post? Here it is. I started writing error checking code in the program that processes the input. What if there is no value specified for trace? Do I want to warn people, or just let it default to false? "Wait a minute," I thought. This is really a job for an XML schema. So, I quickly created one.

Maybe it's just me, but that strikes me as moving forward. It's like development rather than clean-up.

Do You Want 1000 Entities Cooperating? OK with me!

2010-10-15T15:22:00.000+02:00

Current issues #1: Configuration Files and Processing; reported the importance of configuration files and the need to handle them more "generically" than in the prototype. One particular problem stemmed from the fact that using multiple distributed copies of HLL was a sudden flash insight during prototyping.

Building the prototype with a robotics example application close at hand, I originally thought any user interface would communicate with the robot's HLL directly. That would be the same as communicating with the robot. Then it occurred to me that the Command Center (user interface) needs its own separate intelligence to do the things it needs to do intelligently, so it should have its own personal copy of HLL. Then WOW! - Once that's working, you can get as many "entities" (robots, complex specialized experts, - or any distributed entities for any type of application(s)) as needed to do anything. (And with special regard for robotics, it would simplify an effort to get robots to cooperate.)

OK (yes, I'm being verbose - selling HLL) back to the prototype. Before I thought of that, I set up the system to read a simple XML file that gave the host and port of the HLL system, supporting loose coupling. Then I added the browser-based GUI, which also needed to be loosely coupled, so I created another XML file and explicitly handled its reading in the code. Then I decided the Command Center should have its own copy of HLL and explicitly added again. I handled later configurations better, but, so far as the communication information was concerned, it was clear it had to change.

I reprogrammed the handling of the comm configuration file, so that it reads and stores a list of comm entries of arbitrary length. In order to add information for a new connection, the application programmer needs only extend the XML file.

<?xml version="1.0" encoding="ISO-8859-1"?> <commconfig> <config> <name>server</name> <type>hll</type> <host>anyreachablehost.com</host> <port>4049</port> </config> ... continue ad infinitum </commconfig>

To send a message to any entity in the list, a method called sendCommand() in HLL's HLLCommUtils class is used.

response = hllCommUtils.sendCommand(commandMessage, "server", true);

sends a message to the "server" at the host and port specified in the XML above, and receives a response. The sendCommand() method is used whether the message is being passed internally ("server" is in fact currently the reserve word for some of HLL's basic internal communication) or to another HLL installation 1000 miles away, using whatever naming convention is chosen for identifying HLL installations. It's only required that the names are unique.

Both "commandMessage" and "response" are complex objects, allowing complex messages to be passed back and forth easily. A variety of message formats are in fact supported; i.e. SOAP, java objects, strings ... The commandMessage can contain information on the recipient of the message that goes beyond host and port. Issue #2 is about making these messages FIPA compliant.

US physics professor: 'Global warming is the greatest and most successful pseudoscientific fraud I have seen in my long life'

2010-10-11T20:16:00.000+02:00

Newton: "Fie on you, Hansen, Mann, Jones et al! You are not worthy of the name scientists! May the pox consume your shrivelled peterkins!"

Harold Lewis is Emeritus Professor of Physics at the University of California, Santa Barbara. Here is his letter of resignation to Curtis G. Callan Jr, Princeton University, President of the American Physical Society.

Anthony Watts describes it thus:

This is an important moment in science history. I would describe it as a letter on the scale of Martin Luther, nailing his 95 theses to the Wittenburg church door. It is worthy of repeating this letter in entirety on every blog that discusses science.

It’s so utterly damning that I’m going to run it in full without further comment. (H/T GWPF, Richard Brearley).

Dear Curt:

When I first joined the American Physical Society sixty-seven years ago it was much smaller, much gentler, and as yet uncorrupted by the money flood (a threat against which Dwight Eisenhower warned a half-century ago). Indeed, the choice of physics as a profession was then a guarantor of a life of poverty and abstinence—it was World War II that changed all that. The prospect of worldly gain drove few physicists. As recently as thirty-five years ago, when I chaired the first APS study of a contentious social/scientific issue, The Reactor Safety Study, though there were zealots aplenty on the outside there was no hint of inordinate pressure on us as physicists. We were therefore able to produce what I believe was and is an honest appraisal of the situation at that time. We were further enabled by the presence of an oversight committee consisting of Pief Panofsky, Vicki Weisskopf, and Hans Bethe, all towering physicists beyond reproach. I was proud of what we did in a charged atmosphere. In the end the oversight committee, in its report to the APS President, noted the complete independence in which we did the job, and predicted that the report would be attacked from both sides. What greater tribute could there be?
How different it is now. The giants no longer walk the earth, and the money flood has become the raison d’être of much physics research, the vital sustenance of much more, and it provides the support for untold numbers of professional jobs. For reasons that will soon become clear my former pride at being an APS Fellow all these years has been turned into shame, and I am forced, with no pleasure at all, to offer you my resignation from the Society.
It is of course, the global warming scam, with the (literally) trillions of dollars driving it, that has corrupted so many scientists, and has carried APS before it like a rogue wave. It is the greatest and most successful pseudoscientific fraud I have seen in my long life as a physicist. Anyone who has the faintest doubt that this is so should force himself to read the ClimateGate documents, which lay it bare. (Montford’s book organizes the facts very well.) I don’t believe that any real physicist, nay scientist, can read that stuff without revulsion. I would almost make that revulsion a definition of the word scientist.
So what has the APS, as an organization, done in the face of this challenge? It has accepted the corruption as the norm, and gone along with it. For example:
1. About a year ago a few of us sent an e-mail on the subject to a fraction of the membership. APS ignored the issues, but the then President immediately launched a hostile investigation of where we got the e-mail addresses. In its better days, APS used to encourage discussion of important issues, and indeed the Constitution cites that as its principal purpose. No more. Everything that has been done in the last year has been designed to silence debate
2. The appallingly tendentious APS statement on Climate Change was apparently written in a hurry by a few people over lunch, and is certainly not representative of the talents of APS members as I have long known them. So a few of us petitioned the Council to reconsider it. One of the outstanding marks of (in)distinction in the Statement was the poison word incontrovertible, which describes few items in physics, certainly not this one. In response APS appointed a secret committee that never met, never troubled to speak to any skeptics, yet endorsed the Statement in its entirety. (They did admit that the tone was a bit strong, but amazingly kept the poison word incontrovertible to describe the evidence, a position supported by no one.) In the end, the Council kept the original statement, word for word, but approved a far longer “explanatory” screed, admitting that there were uncertainties, but brushing them aside to give blanket approval to the original. The original Statement, which still stands as the APS position, also contains what I consider pompous and asinine advice to all world governments, as if the APS were master of the universe. It is not, and I am embarrassed that our leaders seem to think it is. This is not fun and games, these are serious matters involving vast fractions of our national substance, and the reputation of the Society as a scientific society is at stake.
3. In the interim the ClimateGate scandal broke into the news, and the machinations of the principal alarmists were revealed to the world. It was a fraud on a scale I have never seen, and I lack the words to describe its enormity. Effect on the APS position: none. None at all. This is not science; other forces are at work.
4. So a few of us tried to bring science into the act (that is, after all, the alleged and historic purpose of APS), and collected the necessary 200+ signatures to bring to the Council a proposal for a Topical Group on Climate Science, thinking that open discussion of the scientific issues, in the best tradition of physics, would be beneficial to all, and also a contribution to the nation. I might note that it was not easy to collect the signatures, since you denied us the use of the APS membership list. We conformed in every way with the requirements of the APS Constitution, and described in great detail what we had in mind—simply to bring the subject into the open.<
5. To our amazement, Constitution be damned, you declined to accept our petition, but instead used your own control of the mailing list to run a poll on the members’ interest in a TG on Climate and the Environment. You did ask the members if they would sign a petition to form a TG on your yet-to-be-defined subject, but provided no petition, and got lots of affirmative responses. (If you had asked about sex you would have gotten more expressions of interest.) There was of course no such petition or proposal, and you have now dropped the Environment part, so the whole matter is moot. (Any lawyer will tell you that you cannot collect signatures on a vague petition, and then fill in whatever you like.) The entire purpose of this exercise was to avoid your constitutional responsibility to take our petition to the Council.
6. As of now you have formed still another secret and stacked committee to organize your own TG, simply ignoring our lawful petition.
APS management has gamed the problem from the beginning, to suppress serious conversation about the merits of the climate change claims. Do you wonder that I have lost confidence in the organization?
I do feel the need to add one note, and this is conjecture, since it is always risky to discuss other people’s motives. This scheming at APS HQ is so bizarre that there cannot be a simple explanation for it. Some have held that the physicists of today are not as smart as they used to be, but I don’t think that is an issue. I think it is the money, exactly what Eisenhower warned about a half-century ago. There are indeed trillions of dollars involved, to say nothing of the fame and glory (and frequent trips to exotic islands) that go with being a member of the club. Your own Physics Department (of which you are chairman) would lose millions a year if the global warming bubble burst. When Penn State absolved Mike Mann of wrongdoing, and the University of East Anglia did the same for Phil Jones, they cannot have been unaware of the financial penalty for doing otherwise. As the old saying goes, you don’t have to be a weatherman to know which way the wind is blowing. Since I am no philosopher, I’m not going to explore at just which point enlightened self-interest crosses the line into corruption, but a careful reading of the ClimateGate releases makes it clear that this is not an academic question.
I want no part of it, so please accept my resignation. APS no longer represents me, but I hope we are still friends.

Hal

Harold Lewis is Emeritus Professor of Physics, University of California, Santa Barbara, former Chairman; Former member Defense Science Board, chmn of Technology panel; Chairman DSB study on Nuclear Winter; Former member Advisory Committee on Reactor Safeguards; Former member, President’s Nuclear Safety Oversight Committee; Chairman APS study on Nuclear Reactor Safety

Chairman Risk Assessment Review Group; Co-founder and former Chairman of JASON; Former member USAF Scientific Advisory Board; Served in US Navy in WW II; books: Technological Risk (about, surprise, technological risk) and Why Flip a Coin (about decision making)

Eventually, it will be illegal for humans to drive

2010-10-10T14:31:00.000+02:00

Google is now telling us that they are behind a project developing cars that drive themselves in traffic.

It's been a "secret" project for a while, according to the report; but they're working with people in a geographic area that's been heavily funded in robotics and unmanned vehicles and has taken home some trophies in competition. (DARPA Grand Challenge)

I'm not familiar with google's autonomous vehicle technology; not being in their inner circle of secret friends. So, I can't tell you anything about how good it really is. And, since they're not using HLL (yet, or as far as I know), I'm not going to endorse their effort. :)

I just thought I'd comment on the first response I got after posting their article link to my Facebook page. "No thanks. I prefer to be the one making decisions behind my wheel ;-)"

I'm not picking on the guy who said it. His comment undoubtedly represents the feelings of a lot of people. It's just a prediction; something I've been quite good at, and probably am even more so in my old age.

But this prediction is at least based on straightforward logic. It's pretty easy really. Autonomous vehicles already outperform humans in a number of ways, and we can expect even more improvement in the future. Most auto companies that have invested in autonomous technology have focused the most attention on safety. Step one is using sensors to detect and understand the environment and surrounding traffic, and to warn or avoid dangerous situations.

The more difficult challenge is to accurately predict when autonomous vehicles will be accepted by state law, opening the door to mass production and sales, which will in turn increase investment in research and development even further and increase the pace at which further improvement is realized. I'm optimistic, not just based on what I've said in this paragraph, but based even more on R&D I've been involved with. We can increase the pace of improvement dramatically, and accomplish things that humans cannot. (Yes, the age of AI is upon us - and yes, we're still human. It's the AI you see ...)

"Eventually, it will be illegal for humans to drive," I commented on Facebook.

"By that time it will be illegal for us to think and our humanity will have already been robbed," responded my Facebook friend.

I understand the sentiment (which is why I do indeed take the conversation seriously) but think the two issues are separate. It will eventually be illegal for humans to drive on public roads and highways because a much safer alternative will be available. Humans driving cars will be considered (relatively) too dangerous. Why should the rest of humanity take the risk of being slaughtered by accidents, when such things are extremely rare when the machine does the driving?

I believe that you'll still be allowed to do most of the thinking, at least for a while. An autonomous vehicle doesn't care whether you go to Aunt Suzie's or the race track on Saturday. But one day, even the arguments about whether it's faster to take the Lincoln or Holland Tunnel will be a thing of the past. Honestly, do you think you'll miss it?

Can Unmanned Robots Follow The Laws Of War?

2010-10-05T10:45:00.000+02:00

NPR interviews Patrick Lin, an assistant professor of philosophy and research director of the Ethics and Emerging Sciences Group at California Polytechnic State University; and Joanne Mariner, director of Human Rights Watch's Terrorism and Counterterrorism Program.

I would like to comment briefly on what seems to be settling in as presumptive knowledge regarding technology choices. I'll blog more extensively on this later, sorting it out with HLL; which gives you a hint as to why I interrupt this announcement to comment. Keep in mind that I'm only responding to an NPR interview, not an in depth thesis, and that I've already mentioned that the interdisciplinary discussion on robot ethics is a good thing - so, I discuss. (I'll in fact be picking at just one specific point and think the interview was a good one.)

Patrick Lin, and others, state that increasing machine intelligence / autonomy come down to reliance on either simple rules or learning technology, and that with learning technology, we will not be able to predict behavior. So, the technical choices don't look good.

My quick techie response is first to challenge people to tell me how it is that critical human decision making doesn't fit the rule model, then I'll make what is apparently some startling statements about machine learning.

The laws of war, and other basic decisions can be expressed as rules. if CIVILIAN-NON-COMBATANT then DON'T-FIRE seems to make sense (even if the machine recognition problem is difficult). if ACTION-NOT-SAFE then CANCEL. if OUTNUMBERED then RUN-AWAY. if BATTLE-WON then STOP-FIRING. There just seems to be a whole lot of basic stuff that can be covered by rules - even simple ones. And doesn't this fit the human decision-making model pretty well? (Which is why everyone understands this comment.)

Regarding "unpredictable" learning technology, it seems to me that autonomy is at least to some extent synonymous with lack of predictability - just like with humans and other animals. That seems logical, but in fact, there are effective ways to place limits on the range of behaviors an autonomous robot would develop and use. Learning robots can be programmed to go somewhere and do something, for example, with learning / adaptation used to allow them to adapt to conditions. In the laboratory for example, four-legged robots with a broken leg have adapted their gate to three legs. If a humanoid robot limps the last mile to get home, due to a broken part, that doesn't change the mission. My general point is that design engineers can still control what learning / adaptive robots are programmed to do, even while there's some autonomy in how they do it.

In my contribution to Gerhard Dabringer's interviews below, I spend a section roughly outlining a development process (very generally), that includes training and testing. Even for development engineers with little knowledge of machine learning, I think it makes a worthwhile point. Although the character of development of learning machines is at some points different than traditional development, the overall process is the same. Quality assurance doesn't become obsolete in developing, using, and maintaining these advanced systems.

For a broader debate, there is a series of interviews conducted by Gerhard Dabringer, Austrian military Institute for Religion and Peace. Click here for the interviews and more.

English translation of a Swedish documentary on the same topic: click here.

Roboethics and Robot Ethics

2010-10-02T13:41:00.000+02:00

I mentioned in a previous post that I would blog on robot ethics. Let me meander a bit before getting into technical detail on how this relates to HLL. (I mean that I'm not going to get into that detail in this post. This post is a meanderer on the topic.)

The international discussion on robot ethics involves interacting with people from a variety of academic disciplines, such as moral or ethical philosophers, as well as other engineers and scientists who are interested in the subject. In my view, the interdisciplinary discussion is both quite interesting and valuable.

Me – I'm an engineering scientist type. Although I'm willing to opine on just about anything, when I discuss robot ethics, I typically try to remain in my engineering persona (which is not so hard for me).

I would break the discussion in two. There is a part that is concerned about how humans use technology. Even this breaks down further. There are some who are particularly concerned about the increased autonomy of weapons systems; worrying that machines will increasingly make life and death decisions in military roles. Others (sometimes they overlap) are quite concerned about the use of robots in medicine and particularly elderly care; to what extent will machines replace human contact, etc.

I am assured that naming each area will be the subject of lengthy debate, but there has been at least some preliminary agreement in some quarters that human ethics in the use of robots should be referred to as “roboethics.” (Roboethics Facebook group.)

What does that have to do with engineers? Well, plenty. Engineers invent, design, even manage and use technology. Yes – the decisions of those who pay the bills matter a lot. Even that distinction has a place in the discussion. But it is one of those times when knowledge and awareness of ethical concerns within the engineering community (so to speak) can be important.

The other major branch has - at least in my mind at this early stage - more to do, directly, with HLL. Advances in machine intelligence and autonomy should include advances in autonomous machine ethical decision-making. The ultimate challenge for the “moral machine” is autonomous moral agency. If this seems an interesting subject to you, I will again suggest Wallach and Allen's book; Moral Machines, Teaching Robots Right from Wrong. Their blog is (click) here.

And here's a link to the Robot Ethics Facebook group.

Five Signs You Need HTML5 WebSockets

2010-10-01T18:28:00.000+02:00

HTML5 WebSocket is an important new technology that helps you build engaging, interactive, real-time web applications quickly and reliably. Sure, HTML5 WebSockets may be the best thing since sliced bread, but is this new technology right for you?

This article identifies five types of web applications that will benefit from HTML5 WebSockets. So, without further ado... give me five!

The Five Signs

1. Your web application has data that must flow bi-directional simultaneously.
2. Your web application must scale to large numbers of concurrent users.
3. Your web application must extend TCP-based protocols to the browser.
4. Your web application developers need an API that is easy to use.
5. Your web application must extend SOA over the Web and in the Cloud.

Read the rest: Five Signs You Need HTML5 WebSockets

Man Controls Robotic Hand with his Mind

2010-10-01T17:53:00.001+02:00

WiFi on Steroids

2010-10-01T16:40:00.000+02:00

On September 23, the Federal Communications Commission approved new rules allowing so-called white space spectrum to be used for what has come to be called "WiFi on steroids." White spaces refer to radio airwaves that are not used by broadcasters. According to FCC chairman Julius Genachowski, the opening up of this spectrum will provide a major "platform for innovators and entrepreneurs." What are likely to be some of the first uses of this technology? What impact will the rules have on wireless operators and on companies such as Microsoft, Dell and Google, which have been pushing the FCC to implement the new rules? Wharton legal studies and business ethics professor Kevin Werbach, who has been working closely with the FCC on its latest action and other initiatives, answers these questions during an interview with Knowledge@Wharton.

Continue story, including video discussion: What the New FCC Rules Will Mean for Wireless Users

How to Join the HLL Open Source Project

2010-09-29T22:36:00.000+02:00

The High Level Logic (HLL) Open Source Project is hosted on http://java.net; and joining the HLL project is just like joining any other project hosted on java.net.

1. To become a member of the project, you first need to register (free) at java.net.

2. Then you need to contact me by email. Include your registered java.net name and ask to be added to the project. -> my email.

I will grant you Observer status. Then we can chat if you want to do something special for the project.

Otherwise, feel free to sign up for email discussions and announcements, or visit the project forum and start to discuss something.

BTW: Have you subscribed to this blog yet? What about the High Level Logic (HLL) Facebook group? Note that all the page information and my email address are in the upper right hand corner of this blog page.

The Reincarnation of SOA - Sort of!

2010-09-26T13:38:00.000+02:00

Wouldn't it be nice if a comment on Service Oriented Architecture (SOA) would attract a lot of attention (for my blog, I'm thinking)? Thousands of people googling 'SOA' come right to my site and find out more about HLL. I can't expect that, because I'm provoked on this occasion to comment in response to a discussion that started in January of last year.

VP and Research Director of The Burton Group, Anne Thomas Manes wrote an article entitled, SOA is Dead; Long Live Services. Burton Group surveys IT R&D and provides business consulting services. They have a particular interest in SOA related development. Ms. Manes' noted a high percent of failure in efforts to use SOA and warned that the change-over is disruptive; requiring a full commitment to succeed. Then she added:

The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

One of the many respondents was Kurt Cagle, editor at O'Reilly Media. In SOA is Dead? It's About Time!, he says he is philosophically quite close to Manes with regard to SOA, and adds “that it seemed to be less technology and more marketing term for a number of fairly distinct things, to the fact that distributed technologies are, by their very nature, distributed.”

I particularly enjoyed this comment:

RESTful services - are beginning to gain real traction even as the big-box SOA projects are falling to the accountant's axe. The publish/subscribe model in which what you're publishing are not blogs but data documents (think XBRL or HL7) performs the same type of decoupling that message-oriented SOA did, but completely abstracts the intent from the process of communication.

Now what about HLL? First off, I have to say that I tend to use the dictionary. Not some specialized up to date listing of technical terms – you know, the plain old English language dictionary. I helps to keep me from getting confused by marketing hype. To me, the term “Service Oriented Architecture” refers to an architecture that is oriented to providing services. It's a general term. If you are going to use HLL in support of providing services, that's fine. It can do that (and I think you should). Just don't say something like HLL is an implementation of SOA. SOA isn't a specific thing, so it's grammatically confusing at the very least. SOA isn't itself a technology, even though there seems to be a set of rather basic requirements to do a good job of it.

In the light version of HLL, sockets are used in support of loosely coupled communication. What's generically called the "Java EE" version will probably use JMS. In core processing, HLL will use FIPA to “abstract the intent from the process” in a way that facilitates communication with other systems. Traditional XML (and even SOAP) processing is also supported … and ... HLL actually allows message passing through a variety of structures using the generic 'Object' with object type recognition on the receiving end. The choice for application happens out in the application software, unencumbered by HLL's core architecture.

As for the difficulty of implementing SOA systems – remembering that HLL is HLL and isn't marketed this way at all (although by all means, if SOA is what you want, I'd be pleased if you'd take an interest in HLL) – HLL provides the structure. I don't see it as having the problems the other author's describe. It's flexible. You can centralize to the extent that centralization makes sense, and you can also put copies of HLL on many machines, specializing each set of applications they support, give them access to remote applications and services, either directly or through another copy of HLL.

They seem like old problems. Too boot, HLL is very resource oriented, so much so that I'm almost tempted to refer to its architecture as an ROA - well, maybe I should. If services is what you want, how are you going to do that? (The question how is so very fundamental to engineering.) Well, depending on how you define "resources" (check the dictionary again) - using an ROA might be the answer. Rather trivial once you say it. How are you going to provide services? Is there even any way to do that without using resources?

Well, that's all for now. This entry was just meant to be a quick comment; and it really is - nothing more.

Google Programmer Wanted

2010-09-24T11:40:00.000+02:00

HLL Issue #12 - Fast Processing Large Amounts of Distributed Data

Google is exceptionally good at dealing with large amounts of distributed data. If you haven't tried the latest version of Google Chrome, you should; but you already know that the Google search engine now comes close to performing miracles. Google also offers an API and an opportunity to use their physical infrastructure for rapid processing of large amounts of distributed data in your applications.

It would be of interest to this project if someone is interested in investigating the use of Google technology to support HLL applications with large amounts of distributed data. I (project owner rogerfgay) would be happy to support such an investigation with ideas on the concept and integration with HLL.

Becoming part of the HLL project requires (free) registration at java.net. Then send me your registered name to request "observer" status for the project: hll.dev.java.net.

High Level Logic: Rethinking Software Reuse in the 21st Century

2010-09-20T17:20:00.001+02:00

Introduction

An application programmer spends six months perfecting a set of components commonly needed in the large company that employs him. Some of the components were particularly tricky and key pieces required very high quality, reliable and complex exception handling. It has all been tuned to run quickly and efficiently. Thorough testing has demonstrated his success. Part of his idea of “perfection” was to build in a way that the software, even many of the individual components, could easily be reused. But it is surprisingly likely that no one outside of a small group within the project will ever hear of it.

Tens of thousands of programmers building thousands of applications, repeatedly building the same functionality over and over again. A collective nightmare for CFOs. There are those who believe that the problem has been addressed with “best practice” object oriented programming techniques, enterprise frameworks, and strategic development of specialized open source systems. Certainly they are right – up to a point.

While many available tools and good programming technique offer opportunities to reuse software, and most definitely reduce the need to rebuild many “lower level” (relatively speaking) functions, they also facilitate development of much more complex systems and provide a plethora of gizmos for doing old things in new ways, producing a never-ending stream of reasons to update what has already been done. Out there on the edge, where application programming actually takes place, the software reuse problem is a moving target.

Generally speaking, the benefits of software reuse far outweigh the costs. [1] But in the messy world of real-world application development, the challenge can be complex. Many managers value rapid prototypers over “best practice” engineers, not understanding that building on somewhat sloppy early results will typically and dramatically increase project time and cost and reduce quality. In larger organizations with shared interests, they wonder which project should bear the increased cost of building reusable software components? Who pays the cost of searching the (sometimes huge, distributed, and insufficiently documented) code-base to look for possible matches? Should a software project focus time and money on special packaging, documentation, and “marketing” material to promote reuse of components it builds?

I believe it is possible to realign the software development process in a way that will make everyone happy; from the executives who will see measurable improvements in productivity, to project managers pushing for rapid results, to the programmers who fantasize about widespread use of their best work, to the CFOs who see the company mission fulfilled on a smaller software maintenance budget.

Such a dramatic statement needs a theatrical follow-up. In the spirit of The Graduate, I just want to say one word to you – just one word. Are you listening?

Configuration.

Exactly what do I mean by that? There is a great future in configuration. Think about it. Will you think about it? … Shh! Enough said. That's a deal.

OK, it's not actually enough said in this context. I'll get back to “configuration” below. What I want you to think about first, really think about, is that this is the age of software components.

In the distant past, it was easy to see that it would be useful to represent often repeated binary sequences in hexadecimal code, then an obvious step to package sections of code into a machine language to handle common operations at a higher level. Then combine those into commonly used functions. It's been almost a half century since we got a little excited about “structured programming.” We built functions and libraries, and once again noticed that program structure and flow as well as development tasks often had commonalities across applications. Special tools emerged. It has been thirty-five years since the first IDE was created.

Believe it or not, it has been a half century since an object oriented programming language with classes and instances of objects, as well as subclasses, virtual methods, co-routines, and discrete event simulation emerged from research in artificial intelligence (Simula 67). C with Classes was renamed C++ in 1983 and developers quickly replaced their C compilers with C/C++ compilers. The Java Language Project was initiated in 1991 and Sun Microsystems offered the first “Write Once, Run Anywhere” public implementation in 1995 and the first release of the Java Enterprise Edition in 1999. This is the age of software components. But even one decade is a very long time in the software world. One might almost expect that something new is about to happen.

Beyond Guestbooks and Smiley Faces

If you're entrepreneurial, perhaps you have already realized that you could package sets of useful components as finished product suites (components = products). If you are an independent consultant or operate a specialized software development company, you can offer high quality services based on proven technology with your own product suite(s). (Shame on you if you don't already.)

But let's say that you want to build a complete system, for some purpose, that does something besides impress people with its quality and reusability in the development process – an application. Adaptation by configuration is pervasive. Here are some examples.

Word processing software serves a very specialized purpose. It is adaptable by configuration. You can install specialized language support, adjust the characteristics of various text blocks, add templates for complete (reusable) document layouts, and even adapt it for use by the visually impaired. Some word processing systems are also extensible.

Lotus Notes has a history that reaches back into the 1970s (PLATO Notes). It is familiar to many software developers (and others) as an interactive, networked system that is adaptable (by configuration) to the specifics of a project or other activity, and also extensible. This is a bit more general than a word processor, providing a suite of services, but still somewhat specialized. IBM offers both extensions and tools. Custom code can in fact be added to extend the capabilities of the out-of-the-box system. Extending the concept, Lotus Sametime is offered as middleware for building custom networked applications.

WordPress “is web software you can use to create a beautiful website or blog,” says the WordPress website. “We like to say that WordPress is both free and priceless at the same time.”

The core software is built by hundreds of community volunteers, and when you’re ready for more there are thousands of plug-ins and themes available to transform your site into almost anything you can imagine. Over 25 million people have chosen WordPress to power the place on the web they call “home”.

People all over the world build and post their own components. It doesn't take a software professional or layers of bureaucracy to select and add powerful new interactive features (beyond guestbooks and smiley faces) to customize websites. Welcome to the 21st century (and pervasive CMS)!

The Brave New World

What if you could do that with all software development? And what if a major portion of the reusable software components in a company, starting with their design, were treated seriously as independent internal products rather than vaguely outlined portions of a large pile of 1s and 0s? The idea might be much more practical than you think.

The shift to object oriented programming changed the way programmers think about creating systems. Components are what systems are made of these days. This major technological paradigm shift has also had a major impact on project process; which now leans toward “lean,” discrete, and agile. [5]

Some of the most complex and potentially expensive aspects of software reuse involve getting all the software organized, identified, documented, and searchable. But consider what is already inherent in the tools and processes commonly used by modern software engineers. Software objects are arranged in packages. In best practice, naming of packages and components is systematic and aims to make functional purpose easy to recognize. Package identifiers can also serve to direct programs to the physical location of each component. Documentation on individual objects, arranged in packages, can be automatically generated (easy to organize and keep up-to-date).

Best software practices encourage reusability. If I'm creating an application that reads and interprets 25 XML files, it only makes sense to write one (only one) general purpose read and parse component for XML files, so long as that is possible, rather than new code for each file. Only that part which must be treated uniquely requires additional code.

My experienced observation is that much of the time, in common practice, building nifty general purpose code is less expensive than building sloppy spaghetti code. Building good code from the start dramatically decreases project time and cost. There will be fewer avoidable complexities in downstream development, fewer bugs, and consistently higher quality. Consider also that experience matters. Developers who spend their careers building good code, not only prefer doing the job right, but become extremely efficient at it. When they design, what will come to their minds is good code, not junk. When they implement the design, they are quite familiar with the techniques and details needed to build good code.

From a variety of perspectives, developing reusable components in the spirit of discrete products is beneficial, and the time is right. What more is needed then, to maximize the benefits of software reuse?

Regular Stuff + Artificial Intelligence = Something

The Java language and frameworks like Java EE continue the development path that started with binary sequences in the first section of this article. They differ in that one does not generally innovate on the concept of adding two integers, for example. Initially, getting good fast versions of common functionality for a variety of machines was the point. Both Java SE and Java EE (and others) provide support for higher level functionality supporting, for example, a variety of ways to move data around on a network for display and processing.

In the world of artificial intelligence research however, it seems people enjoy branching off in new directions, “moving things around” (so to speak) to change the character of computing. The old research definition for AI was simply to get computers to do things that at present, humans do better. From the start, people thought about moving the human role (part of it anyway) into the computer.

In the mid to late 1980s, complex rule-processing software came on the market. New companies emerged marketing “expert systems” tools, large companies invested, and more powerful rule-processing capabilities were added to existing commercial products like database systems. A slightly deeper look yields something more interesting than a packaged way to process lots of “if-then” statements. AI researchers wanted to move logic out of application programs and into a general processing engine, with application logic treated as data. I'm going to cast that into the perspective I offer now, with a description that the researchers and developers at that time may never have used. Expert systems applications were built by configuring the processing engine with a rule base (and other information).

More powerful systems like KEE became commercially available in the same decade, incorporating a new and powerful programming component - objects - into the mix. The object oriented programming concept itself repackaged some of the common elements of complete applications into individual components; not just by definition, but by encouraged design practice. Its introduction was disruptive, setting vast numbers of working engineers to the task of rethinking how software systems should be written. An “object” you say? Sounds classy!

My agent is on the phone.

“A software agent is a piece of software that acts for a user or other program in a relationship of agency,” says Wikipedia (citing two sources [2][3]). Agent technology also has a history. The concept can be traced back to 1973 [4]. An actor is "a self-contained, interactive and concurrently-executing object, possessing internal state and communication capability.” One might call it the ultimate object.

Agent technology has already emerged from artificial intelligence laboratories. Modern agents extend the “Write Once, Run Anywhere” idea, even to the extent that there are what might be called “door-to-door” salesman varieties; traveling agents (also called robots, bots, web spiders and crawlers and even viruses) that move around the Internet (sometimes duplicating themselves) to perform tasks.

The telecommunications industry recognizes the importance of a new technology that screams to be used as a central processing system for a wide range of applications that can service the wide range of networked devices available today. JADE (Java Agent DEvelopment Framework) is a free software Framework distributed by Telecom Italia, that “simplifies the implementation of multi-agent systems.”

It changes the way you think about software development. Don't worry about the wide range of interfaces needed for so many devices. They're supported. Don't worry about the complexities of communication. The code is written and maintained by someone else. This goes beyond the relatively “low level” programming components available in IDEs and support offered by higher level development frameworks like Java EE. Much of “the system” already exists. Just focus on the very specialized components needed for your particular application that can be cast into the agent framework. Only that part which must be treated uniquely requires additional code.

You then let the framework know when your agents are needed. When they are, they get the call; automatically. And by the way; intelligent agents can sense when they are needed and respond appropriately, even learn and adapt to new circumstances.

Sometimes one is not enough. A multi-agent system (MAS) is a system composed of multiple interacting intelligent agents. Multi-agent systems can be used to solve problems which are difficult or impossible for an individual agent or monolithic system to solve. Examples of problems which are appropriate to multi-agent systems research include online trading, disaster response, and modeling social structures.

High Level Logic

OK, quick! Think of a way to go beyond what's been discussed so far.

How about this?

Design what is basically an agent-type system that easily interacts with others of its own kind installed anywhere in the world and may also communicate with other agent systems facilitated by use of standard message structures. (Note that the FIPA standard message offers SOAP level power.)
Identify high level logical processes that you expect to be common to thousands of applications (maybe every conceivable application?) and provide generic engines for doing that part of the work; both in the spirit of “expert systems” above – i.e. moving additional, common, higher level application logic to a generic engine for the first time and embellishing on the new generic processor and also support more basic processes like intelligent XML, encryption, authentication, rule-processing ....
Provide a “general problem solving” (high level process … what do you want, what are the variables … etc.) engine.
Include the ability to carry out more complex processes by implementing custom plans.
Devise an even higher level generic processor that ties all of the above together in a top-level process.
Allow application developers to extend and customize if they wish, without destroying the ability of one system to interact, cooperate, and share with the others.
Provide a simple way to tie in a GUI – as needed – for a great variety of devices.

One more thing, while we're on the subject of code reuse.

Provide a mechanism to call upon any level of reusable code, from large systems to discrete components integrated through plans, rule-processors and other high level structures. Support options for utilizing common code remotely (if, for example, the process utilizes other remote resources), to fetch and utilize temporarily, and to fetch and store locally.

Now what you have is an outline for a system known as “High Level Logic” - HLL. The High Level Logic (HLL) Open Source Project stems from a history that goes back into the 1980s, as a concept for unleashing the power of expert systems. Prototype software was more recently built as part of a larger intelligent robotics project. The commitment to open-source development was made in July, 2010.

Although the development project is now (September 2010) at an early stage, there is sufficient software available to create applications. The plans to complete the first complete “light-weight” version, using only Java SE, that will have the full set of characteristics described above are quite concrete, already committed to specific technical issues logged in the project's issues tracker. An outline for a somewhat heavier version using Java EE components is given on the project description page.

Yet Another Path to Code Reuse

Subtly perhaps, four different approaches to code reuse have been mentioned and illustrated in this article.

First, the development of higher-level languages involved assigning names to commonly used bits of logic in lower level coding and the development of tools to translate (interpreters, compilers, …) back into lower level code. One common implementation of the lower level code was then used by everyone using the same higher level language (compiler …).

Second, object-oriented computing involved re-organizing some of the processes common to applications from the complete application level, down to component level.

Third, a more open mass use of certain web-based technologies led to common application cores and shared extensions. (Proprietary: Lotus Notes → Open: WordPress; and also more on the extreme techie side, consider the history of Sun Java development).

Fourth, highly innovative research identified distributed application logic that could be extracted into generic processing engines.

At least one more exists, which will be the subject of later articles. Learning and adaptive software has already reached well into the stage of commercial use. Developers write code explaining the results they want. The learning system automatically creates the code. There are many circumstances in which the same specification code written by developers can be reused on various platforms (physically different robots for example) in different environments and for different purposes (identifying and moving different objects in new environments for example). Even existing application code can be reused and automatically adapted to differences.

The direction of HLL incorporates all of the above providing a useful general purpose application platform rather than a specialized application platform (like CMS for example). It will be part of the purpose of the HLL Blog to provide further focus on these characteristics of the HLL system.

Given the current state of HLL, there is at least one characteristic that should be emphasized. Application developers focus their coding work only on those components that are unique to their application. There is a great deal of flexibility in what can be done on the application, because – simply – there are no restrictions. Java developers, for example, can write any kind of Java components they wish. The HLL engine can use components from anywhere an HLL system exits on any installed HLL system (component sharing). Components that builders wish to be accessed by HLL are named (like higher level language), and accessible to HLL systems through their configurations.

This aspect of HLL is worth emphasizing. It is the intent, that – especially as an organization builds its library of reusable functionality – application development will be largely a matter of configuration; and that's a very good reason to push reusable code development.

References:

SOFTWARE REUSE ECONOMICS: COST-BENEFIT ANALYSIS ON A LARGE-SCALE ADA PROJECT, Johan Margono and Thomas E. Rhoads, Computer Sciences Corporation, System Sciences Division. (I believe this 1992 article in ACM, which I found freely available on the Internet, is still quite relevant. Margono and Rhoads however, did not say “benefits … far outweigh the costs.” They actually said; “benefits … have so far outweighed the costs. We believe that this will continue to be the case.” Eighteen years later, with a great variety of new advantages mentioned in this current article, it is surely even more true due to long-term technical focus on the issue; and this article recasts the issue in that light. We've come a long way.)
Nwana, H.S. 1996. Software Agents: An Overview. Knowledge Engineering Review, Vol.11, No.3, 205-244, Cambridge University Press
Schermer, B.W., Software agents, surveillance, and the right to privacy: A legislative framework for agent-enabled surveillance. Leiden University Press, 2007, p.140.
Carl Hewitt; Peter Bishop and Richard Steiger (1973). A Universal Modular Actor Formalism for Artificial Intelligence. IJCAI.
Agile software development methods Review and analysis, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, and Juhani Warsta, Espoo 2002, VTT Publications 478, 109 p.

Robot Ethics and HLL

2010-09-19T11:05:00.000+02:00

Work on my next blog post just hit 2500 words (which I hope are well-chosen) and it looks like I'll be busy for a while trying to give a good introduction to the HLL concept, character, rationale and purpose (and state of project, etc.) before delving more deeply into the technology (and of course, working on the software).

There is however, a topic of special interest that I would like to write more about, particularly w.r.t. what HLL can have to do with creating autonomous moral agents, but for now will simply introduce quickly with some links.

Brainstorm Responds to Robot Ethics Challenge comments on the use of HLL in the context of international discussion on the topic.

Ethical and Legal Aspects of Unmanned Systems Interviews is a set of interviews conducted by Gerhard Dabringer, Institut für Religion und Frieden, for the Austrian military. My little contribution, which contains a similar description of HLL to that in the article above (and more) starts on page 169, titled; A Developer’s Perspective.

English language transcript of a Swedish television documentary on robot ethics (includes limited coverage of Barcelona experiment mentioned in my interview - video also available; see transcript).

If the topic, autonomous moral agents seems intriguing to you, I suggest Wallach and Allen's book; Moral Machines, Teaching Robots Right from Wrong. Their blog is (click) here.

And here's a link to the Robot Ethics Facebook group.

What is an Agent?

2010-09-16T14:17:00.000+02:00

This entry includes section 2.1 of A Methodology for the Analysis and Design of Multi-Agent Systems using JADE, by Magid Nikraz1a, Giovanni Caireb, and Parisa A. Bahria aSchool of Engineering Science and Parker Center, Murdoch University, Dixon Road, Rockingham, Western Australia 6168 bTelecom Italia Lab, Via Reiss Romoli, Turin, Italy 10148.

It is intended here as part of a larger discussion on the use of the agent approach in HLL. HLL is not simply another agent platform, so it is important to first note what agents actually are, to allow a clear discussion on the extension that HLL provides. Note that the HLL concept was first conceived in the mid-1980s as a way of unleashing the power of "expert systems." I don't believe I'd even heard of software agents back then. But it is cause to smile, that there is now a well recognized and developing technical approach underlying the HLL "extension." (More on this in future blog posts; I assure you.)

The paper being quoted discusses development methodology for agent systems using JADE as a concrete example. This is also a good topic related to application development using HLL - since developers will need to adapt their process, working more exclusively on their specialized application components, and opening up to the idea that sophisticated, interacting, "intelligent," distributed systems are not so difficult with the right tools; and that software component reuse is taking another big jump in practicality.

HLL is also good for smaller "smart" systems. But even then, the use of standards for communication and message structure facilitates interaction with other agent systems. To roughly quote a new-age adage, the Internet becomes The application.

2.1 What is an Agent?

The term agent is very broad and has different meanings to different people. However, on close observation of the literature, it is sufficient to say that two usages of the term agent can be identified: the weak notion of agency and the strong notion of agency [37]. The weak notion of agency constitutes the bare minimum that most researches agree on, while the stronger notion of agency is more controversial and a subject of active research.

The weak notion of agency denotes a software-based computer system with the following properties [37]:

Autonomy: agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state.
Social ability: agents interact with other agents (and possibly humans) via some kind of agent communication language.
Reactivity: agents perceive their environment and respond in a timely fashion to changes occurring therein.
Pro-activeness: in addition to acting in response to their environment, agents are able to exhibit goal-directed behaviour by taking the initiative.

The strong notion of agency is an extension of the weaker notion, and advocates additional humanistic, mental properties such as belief, desire, and intention [29].

Consistent with the weak notion of agency, one author [13] has gone so far as to say that software agents are application programs that communicate with each other in an expressive agent communication language. Though at first this definition may seem a little simplistic, it allows one to clearly identify what constitutes a multi-agent system, i.e. agents are just pieces of autonomous code, able to communicate with each other using an agent communication language. The view of agents assumed in the proposed methodology is based on this definition. Specifically, the methodology assumes the following definition for an agent:

agents reside on a platform that, consistent with the presented vision, provides the agents with a proper mechanism to communicate by names, regardless of the complexity and nature of the underlying environment (i.e. operating systems, networks, etc).

Thus, the assumed view is exactly the same as that presented in [13], but in addition, the agents have unique names as a means of identification.

This particular view of agents is the only assumption for analysis, while the design is specific to the JADE platform, which is a FIPA-compliant realization of the above vision, i.e. in the design phase, the constructs provided by the JADE platform are assumed.

13. M. R. Genesereth and S. P. and Ketchpel, "Software Agents," Communication of the ACM, vol. 37(7), 1994.

29. Y. Shoham, “Agent Oriented Programming,” Artificial Intelligence, vol. 60(1), pp. 51-92, 1993.

37. M. Wooldridge and N. R. Jennings, “Intelligent agents: theory and practice,” The Knowledge Engineering Review, vol. 10(2), pp. 115-152, 1995.

General Problem Solver

2010-09-15T16:03:00.000+02:00

If you review the initial source-code offering (a cleaned up version of the 2007 prototype) or try the current runnable demonstrations, you may either conclude that HLL does simple things in an overly complicated manner or that it represents a good start on a grander design. It's the latter, and one of the reasons I'm writing this post is to assure you that it's not the former. But this post will end with a comment on "high level" support for a general problem solving method.

HLL has been developed in a way that makes it "open." By that I mean, you can do things with it - lots of things - even things I haven't thought of yet. That's the point. It's supposed to provide support for a broad range of applications, making them easier to build, and once the grander design level is reached in reality, more powerful than you thought your time and budget allowed. Expanding the application with increased complexity or even using your earlier work as "experts" in a larger system is going to be all the easier.

Here are some examples, and remember, you don't need to write all the code for this stuff. That's why there's HLL.

The use of an agent approach to pass messages may seem overly complicated if you're only sending "Hello World!" to another part of your application. You may wonder if you really need sockets to pass the message. If you are building to run on a local machine (Is that a lost art?), then you can set the host to "localhost" and you're fine. If you have reason to make use of more than one machine on a LAN, that works too - just set the host to a local IP address. Communicate with machines around the world - HLL is "open" to that as well - just use an IP address or host name recognizable to the outside world.

Although you can pass messages in other ways within your application code, what about the complexity of an agent's message? If you're passing messages between agent layers (actors), but your needs are simple, you can set messages up to have defaults. Your application code then only needs to specify what it needs to specify. Within the application code, it's still simple. If your need becomes more complex, the agent message standard that will be supported is "open" to allowing you to do that.

And of course, you can write as many "experts" as you wish and make them as complicated as you need - from simply command responses, to complete external systems. HLL is easy to extend into your application world.

The "Hello World!" example is a perfect case for making agent "layers" (actors) look a little silly. All three layers do something unique, but in the end, you've just typed "run" in the console (or used the browser-based GUI), to get "Hello World!" printed out. Well - if you've done much Java programming, your used to that. "Hello World!" is part of the culture - a very simple way of showing the details of how something works. Each of the agent "layers" (actors) is designed to provide a set of support functions - and (eventually) application programmers will be able to define their own actors. The basic three - executive, manager, and expert will always be supported as part of the HLL Core system (with increasing power and grace as time goes by). These three will support things that tons and tons of applications need to do and will also form the initial structure of a larger "organization." (HLL was designed by taking something from nature so to speak - then nature of human work organizations.)

The latter may not immediately seem interesting to general purpose Java programmers who tend to move around a lot. (Or maybe it does if you're entrepreneurial - read on.) Consider the fact that many companies provide software with a specialty area. I've spent enough time in more than one such company to know that various software functionality related to the company's area of specialization is sometimes repeatedly redesigned and rebuilt; something that's not supposed to happen in the age of object oriented reusable software components. Instead, you can define actors with basic capabilities commonly needed in software in that specialty area. Various products can be defined with different sets of "experts" (supported by the same actors). If you're a specialized consultant, you can do the same thing - licensing your software for resale or being paid to write new experts. If you're building something to support a company's internal operations, you can build "actors" to reflect the company organization itself. (Start by thinking about departments of operation).

Best of all - you don't need to maintain the HLL Core software yourself. Somebody else is doing that for you - keeping the technology up-to-date and making it ever more perfect. :)

There is another use of the "sufficient complexity" of HLL that I would like to mention. It's related to XML plans (on the issues list). If you've read though the old ppt presentation (available for download on the right side of this page) this should be familiar. The original HLL concept includes the idea of providing general "high level" support for problem solving. There are five steps involved:

Define the Problem
Collect Information
Perform Analysis
Identify Alternative Solutions
Recommend a Solution

I'm looking forward to getting the core software to the point that I can concentrate effort directly on providing "high level" support that will make it very easy for application developers to apply this particular problem solving approach.

Follow up, see blog entry: The Ghosts in My Machine: Chapter 2

.

Multi-use Browser-Based GUI

2010-09-15T12:51:00.000+02:00

I have already provided one blog entry on the browser-based GUI, about how it's a time killer for development but that there is a reasonable rational for doing it. Now, just a quick word on its specific design. There is actually more than a bit of thought behind it. It has survived several prototyping activities. The reason this is interesting, is that it adds to the idea that browser components can be reused - saving developers time and effort when creating new applications.

Although HLL is really separate from the browser-based GUI, it is the intent of the project to provide reusable software even for the GUI. Especially for applications built with HLL, there seems to be a good opportunity to do so - since the "high level logic" of the application is somewhat predictable. The HLL /GUI pair can even use a common general message format, perhaps based on FIPA for example, or customized to support a company or development house specialization. This idea just leans on good design practice - thinking in layers. Very general communication and processing support can be provided by the HLL GUI. Specialized organizations can extend that capability to provide reusable support for the type of software that they develop and maintain.

The use of frames provides an easy way to modify the content; simply load a different html page into the frame. Another frame can maintain state variables that will allow returning to the same state if you reload an earlier page, or provide an up-to-date state instead (or use AJAX to deliver to / fetch from server or app. - yes, HLL apps. can even incorporate typical, common, everyday ordinary request-response processing). Frames can be resized on the fly or frame content can be expanded to a separate full-screen browser window. I've also been using one frame (upper left with a logo in it) to contain the applet that accepts data pushed in from the outside. It also contains functions to channel the data to the frame.method() where it is used. The upper right frame, which displays title and menu, is what I use to store generally useful javascript functions and state information for other frames.

It can also load or reload the upper left frame(s) to control use of applets. Just to illustrate; imagine a process of switching from one human operator to another in which there is a need for both operators to be online temporarily during the change over. One could switch from a single secure URLConnection to Multicasting during the transition, giving full use to two terminals. Once the new operator is in full control, the communications link is switched back to a URLConnection at the new operator's terminal. There may be a need for multiple applets for some applications. I've typically met that need by stacking smaller frames into the same small upper left corner. (Size doesn't matter).

Here are some visualizations for robot related applications that I created when presenting the HLL concept (in the context of a robotics project) in 2006.

The first suggests use of HLL and the browser-based GUI in a mobile surveillance / security robot application (in a German airport in this illustration).

The next illustration suggests use of HLL and the browser-based GUI in a development tool application for robots that can learn and adapt (using genetic programming). - This comes close to the original concept GUI: with the thought of providing a tool to support development of HLL applications.

The next illustration suggests use of HLL and the browser-based GUI in a related research tool application.

The next illustration, from one of my working prototypes, shows a screen expansion to get a closer look at some XML.

HLL Robotics Demo Video

2010-09-15T09:58:00.001+02:00

I've decided to release a 2007 video of the robot demonstration (which will be available for download with the new version sometime relatively soon). Let me orient you first so you know the relationship between this old video and the current project software downloads.

I created the HLL prototype during the summer of 2007 as part of a much larger robotics software project. HLL was not originally conceived as part of a robotics system, but robotics fits well within the much broader scope of potential applications. As mentioned in more than one blog post already, I originally used Multicasting to the browser, which only worked within a LAN when machines had their security adjusted to allow it. I worked in a completely different city than the rest of the project participants, so a video demonstration - just to bring people up to date and show that something was working - made sense.

The idea behind building HLL during the project was that it would be connected to the robotics software being built on the project; as the upper three layers in what would then be a six layer learning / adaptive software system for robotics. Another package became available at the time of project start that offered somewhat more mature SOA kinds of processing that HLL intended to offer (Microsoft Robotics Studio), which was subsequently used with the other robotics software. The tech. team chose to work with the other software, which had the advantage of already existing, and HLL did not get past the prototype stage.

HLL is still very interesting for robotics, imo; but also a much broader range of potential applications. Nonetheless, there's been a time skip between the 2007 prototype work, which was used to flush out design details, and where we are now. The commitment to open source happened just two months ago, and I've written in an earlier post here about the technical work that's been done since then (browser stuff has been a time killer). So there is actually, pretty good correspondence between what's shown in the video and the state of the software right now - except that the source code is now emerging well from from somewhat chaotic exploratory prototype work and taking shape as real software. (And see "Current Issues" blog post to see where it's going now.)

The robot simulator used during prototype work was very simple. It knows about the "two rooms" displayed in the browser. When a command reaches the robot simulator, it merely calculates a new position in response to the command, and sends it back. When the new position data reaches the browser, the circle (representing the robot) "jumps" to the new position. RE: "jumps", I've written about the graphics issue in an earlier blog post: "Why a Browser-Based GUI? - The Time Bandit". Microsoft is now reportedly supporting SVG and the next release of the robot demonstration should have smooth movements.

Interest in the robot application during prototyping went beyond the fact that prototyping was done in the context of a robotics software project. Two copies of HLL are used that communicate with one another. One copy operates as part of the robotics Command Center. The other is for the robot itself. Each associated HLL "application" suite is different. Each can be physically located in a different place. And there's the potential for a single Command Center to communicate with more than one robot - and for the robots to communicate (intelligently) with one another through HLL.

To get to the point of creating the first demonstration of a "smart" operation of multiple HLL, the (see Current Issues) configuration processing and XML plans needs to be completed (and although not necessary, it would be nice to have the rule-processor). I have been imagining this: The Command Center is the central facility for a many mobile robots at a logistics center. One of the mobile robots is called to join a team to unload a truck. This particular robot is either new or has been working on filling orders or some other task, and has never been involved in unloading trucks. It doesn't even know where "pier 6" is; so it doesn't know where to go to join the team. It doesn't recognize location "pier 6." All the information needed is available at the command center (or could actually be on another robot).

The Command Center issues the command to the robot; to go to pier 6 and help unload the truck. The robot recognizes that it does not know how to get to unload a truck and returns that message to the Command Center's HLL. Knowing whether or not a command is supported is one of the generic jobs of the HLL Executive. The Command Center is designed to help bring new robots into the operation and to support multiple use of robots. It fetches the software needed and returns it to the robot. (We were working on learning / adaptive robotics software, so in that context, this would even work if the only software available was not specifically designed for the type of robot being called into action.)

The robot knows how to go somewhere, but in implementation the manager finds it has insufficient information for the navigation expert to find pier 6. That information is also passed back to the Command Center, which returns an extension to the robot's map. The robot is then able to go to pier 6 and help unload the truck. {Note: This scenario is also a step toward real-time teamwork.)

OK, but that's not what you're going to see in the video. The video just provides a simple report given within the development group that gives evidence that the prototype software is running. It gives some trace information to the browser and the circle "jumps" around in the two rooms. Oh, and BTW - I did figure out why I was getting socket related error messages.

This is an asf video. It does work with Microsoft Media Player, but you might need to coax it to get it started - i.e. select Windows Media Player or open the file from within Windows Media Player. But you can try just clicking on the link and waiting for it to load. Here it is: 2007 robot and command center early prototype demonstration.

Current Issues

2010-09-14T17:07:00.000+02:00

Once you've become familiar with what there is (btw: a quick start guide is in review), probably nothing tells you more about what you can expect in the near future than the project issues list. The Issues Tracker at http://hll.dev.java.net, the project hosting site, currently has 11 issues logged. There are some that I do not believe will be particularly difficult to take care of, and at the same time will greatly benefit application developers. Issue #1 is a good example. XML Based Plans is critical to bringing the manager's role to what it minimally should be. FIPA compliance is quite simple, and then I'll want to apply it, even within the HLL Core (and it also makes for better applications). Rule-processing can be added by using an existing open-source package, but I'd also like to have a simple one specifically owned by and adapted to HLL.

Here's the list with short descriptions:

1. Configuration Files and Processing

Configuration files are quite important to the HLL architecture. In fact, I'd go so far as to say there should be applications built by configuring them rather than always writing new Java code for new application components. Applications should even be able to reconfigure on the fly, allowing them to add new capabilities or modify their processes and plans.

Although I've written code that handles configuration files in a pretty generic manner, I tended to define configuration files one at a time during prototype development as the need arose. The really crumby thing is that the HLL Core code explicitly looks for a particular set of configuration files on start-up. That means, that I'm carrying around a configuration file for the robot demonstration, for example, unless I change the source code so HLL doesn't look for it. That must change; and what I have planned is a master config file that tells HLL what the other config files are; and a flexible enough read and storage process to allow application developers to define their own configuration files.

2. FIPA Compliance

FIPA stands for Foundation for Intelligent Physical Agents and the FIPA organization has put forth a standard for agent messages, available here. If you thought much about the subject, a lot about it will just seem like common sense. The parts of a message include who sent it, where it's supposed to go, and other information allowing tracking of agent processing (and a message of course). The FIPA standard is well thought through and compliance provides the added advantage of facilitating communication with other agent systems.

This seems like a rather easy one at present. I just need to extend the current message object and assure that the elements are named according to the standard. The current version of the code is still small enough that necessary changes to the Java code that processes messages won't take long. Now is the time to do it.

3. Simple JSR-94 Rule Processor

There are a number of places in which rule-processing can increase the power of HLL significantly and simplify application building. The prototype uses server protocols to define the behavior of actors. Server protocols are not difficult to master. Just in case you've never written one, they tend to have if-then statements that direct processing when a message comes in to a server. A nice rule-processing system could turn this part of application building into tool-driven process. Alternatively, an open-source package like JBoss Rules (formerly DROOLS) would add a great deal of power with what is a powerful and straight-forward construction process.

But I'd still like to have at least a simple rule-processor that belongs to HLL. Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

4. XML Based Plans

At present, an HLL manager can use resources. Resources in the form of java objects can contain plans, written in java. I want to bring at least part of this process out of coding and into XML files so that plans are easily configurable without changing source code. Note, this can also lead to an easy way of adding and modifying plans on the fly.

Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

5. Code Review

All project members are invited to review all the source code.

6. Logging

In the prototype, most error handling consists of printing error messages to the console. When the GUI interface is involved, there is some logging supported by Tomcat. We need a better logging system.

7. HLL Server Protocol Modification

The initial issue was that the HLL Core server called an application specific protocol; which means that the Core server needed to be modified for each application. There's been a simple work-around; requiring a generically named server protocol at the top of the application's process: HLLServerThread class. I would prefer to replace that requirement with specification of the application's head server protocol named in a configuration file.

Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

8. GUI Always Initialized

If I now tell you this has something to do with processing configuration files, you should be getting the message that configuration files are important.

9. Multicasting to browsers as option

Readers of this blog already know that I implemented Multicasting to browsers before changing to a URLConnection. Since I've already done it, this issue is assigned to me. I only need to hook it back up again, and (you may have guessed) handle whether it's used or not in configuration files.

10. General Browser GUI Issues List

This is where I'm listing issues for improving the GUI.

11. Security

Eventually, the HLL executive will need to start checking to see if messages received from the outside world come from an authorized source, and even handle encryption for some applications.

Why a Browser-Based GUI? - The Time Bandit

2010-09-12T09:33:00.000+02:00

Since the first experimental prototyping in 2007, HLL has had a browser-based GUI. It's been the most time-consuming part of development. One the one hand, there are lots of different devices out there, not just your desktop, but smart phones and PDAs and the like - in a variety of models from a variety of manufacturers with a variety of technology used. How many of those devices have browsers? Well - most. All that I own. So, I figure if I have a nice cross-browser GUI, it covers a lot of ground.

I've also done lots of interesting experimentation with SVG (Scalable Vector Graphics), which I think it great. SVG is a standard. Support is directly in the browser itself. You build SVG graphics using XML coding. Several browsers are getting close to implementing animation, which will simplify programming for (for example) the graphical robot tracking frame.

On the other hand, I must say it's been a bit painful. Especially when you're trying to do interesting things in the browser, cross-browser applications are not simple, especially if you're including MSIE. Each browser supports what its developers decide to support, and require programming applications to correspond with the functional support available. A working javascript function doesn't necessary work in all browsers. Sometimes you can discover just the right coding so that it will. Sometimes you are forced to detect browser type and support differently built functions depending on what the user is running. It's not like there's perfect up-to-date documentation for each either. Experimentation is required and sometimes you need to google around looking for someone who has posted about a similar problem and find a suggestion for solving it. (Although - if you've been around the block 20 times on all of this - I suspect it's easier.)

Microsoft hasn't been so good at supporting established public standards. It's full of exceptions. Everyone who, for example, has built a cross-browser AJAX function knows that. They are miles behind in support for SVG. There is a plug-in from Adobe that works, but it requires the plug-in to run, and Adobe no longer supports it - so it's apparently not destined to support things like animation. Microsoft has said they'll work on it themselves, but who knows? ↓

(Turns out, somebody did know. MSIE support for SVG announced for the upcoming IE9. See comments below article for more information and links to SVG status charts for browsers.)

The SVG element is but one feature in a particular application. But I think it's an interesting one, and with care, the HLL GUI can provide out-of-the-box support that will help other applications get up and running nicely. I've implemented two different ways of pushing content to the browser and - among other things - that drives graphics animation (think of a circle moving around through "rooms" tracking the movement of a running robot). Microsoft's lack of support for animation seems a longer term problem (perhaps), while Firefox is closer to doing it. Opera is in the lead. To create smooth movement, I'm currently using dhtml. Perhaps something in that code might even turn out to be re-usable.

When I committed to open-sourcing HLL, I decided to move development from MSIE to Firefox as well as implementing a URLConnection push to the browser, replacing a very nice Multicasting version. The latter decision was based on two things. The multicasting version only worked within a LAN and required a policy and modification of the Java security file to implement the policy. Having some experience searching for open-source code myself, it seems to me that the first offering one encounters must be as simple to install and run as possible. Download - click run - not start fooling around with your Java security file. And I have no statistics on the percent of Java programmers who find it easy to create a new security policy. That could be a stopper for many. The URLConnection doesn't even require opening a port and it works from any machine anywhere without any installations or modifications or plug-ins on the client. It just works (although not as nicely as Multicasting at this point). (Note also: the Java EE version will likely use JMS.)

Firefox is of course, a very popular browser. But I also considered the state of their support for SVG. As mentioned, they are behind Opera. It seems to me that playing to the most advanced doesn't really help me build something that most browsers can run. Given that Opera is currently more advanced in their support for SVG, one can proceed with the idea that if it works on Firefox, it will probably work in Opera (even if it takes a little tinkering). Of course, then there's MSIE. Since I already have experience with MSIE, I'm familiar with the limitations of the Adobe plug-in. For MSIE, the application will need to detect browser and reload the frame with the customized MSIE page. Since I built first with MSIE, I'm just a hop, skip, and jump from completing that task when the time comes. (Will be great if I don't need to.) With tinkering, the dhtml smoothing function should work for MSIE as well.

Now here's the painful thing. I'm at the beginning of this project, coding everything myself, while getting the open-source project up and running and now - to keep my schedule - I need to start "marketing" the project and trying to draw some interest. There are now 11 issues posted in the issue tracking system, each of which will enhance HLL considerably on completion. This browser stuff has taken up a lot of my time for adaptations more than gains.

Of course there are frameworks. But I'm spread pretty thin. I've nothing against learning new frameworks - believe me. I'm asking people to learn about mine. It's partly just a matter of time, but also consideration for simplifying the original offering. "Just download and try my code. It's easy." instead of "download, install, learn to use 14 other different packages" kind of thing. (I'm thinking about how to handle this in the future - because there's a lot of good stuff out there that would be useful as add-ons ... I'll likely write about some of them in this blog later) As for time and using a cross-browser framework, no one person can know everything. I don't know at this point - perhaps in hindsight, the time might have been better spent learning a framework rather than doing everything myself ... but the results always seem just one more solution away.

Anyway - the Firefox version seems to be working now, for the most part. I still need to get the dhtml for smooth movement working in context. Then I can get back to enhancing the Java .... HLL itself ... which should produce gain much more quickly. Of course, now I do have a new list of things to do - since my schedule says the open-source project should be underway.

Planning a Tutorial

2010-09-12T00:18:00.000+02:00

I have also started a Facebook group called "High Level Logic (HLL) Open Source Project." Eighteen people joined within the first 24 hours. Several appear to be Java programmers, or at least seriously interested in software. One asked if I could provide a very simple how to example so that he could see how exactly one goes about building an HLL application. Of course - that was a very smart question. There should be a simple "Hello World!" (or better) tutorial showing just what one does to build a working application.

A few Facebook messages later, and there's a general outline for a nice tutorial. I will work on it this coming week - but I still would like to tackle at least one of the issues on the current issues list before doing that. I'll report back on that later. Anyone who ventures far enough into the project to understand the code and review the issues on the list may want to know what's coming soon and how that will effect development.

First Post

2010-09-10T11:07:00.001+02:00

This blog is being started for the High Level Logic (HLL) Open Source development project that is housed on java.net. Yes, for those of you who have not been there, there is a website named java.net. This is not an mistake in which I've accidentally mentioned Java programming resources for networking. If you're interested in open-source, you should sign up for a free account. Although they explain that the site hosts open-source projects involving development in many different languages - I still have the impression that it's Java oriented. Maybe people just got that impression from the name of the site - which is after all, java.net. Started by a small group of Sun employees, I'd guess their thought was to advertise the fact that the site technology itself is very Java oriented - but I am assured that they are willing to house non-java projects.

I'm rather new to the site myself, and to its resources, and was actually attracted to it because it's called java.net. High Level Logic (HLL), which I will be discussing in following posts, is written in pure Java. The first offering is a very light-weight prototype written entirely in Java SE (formerly known as J2SE). But there is already a description of an advanced version using Java EE (J2EE) and integration other open source assets.

Even though HLL is not described yet in this blog, I'll point you to an article that mentions the concept (happens to be about robot ethics, but HLL is a general purpose framework) and to the project website on java.net.

BTW: The company mentioned in the article, iRobis, no longer exists. Contact me directly if you have any interest in HLL or the robot learning software.

2BTW: To access a project on java.net, you must first sign up for a java.net account, then contact the project owner for permission to access the project.

Article: Brainstorm Responds to Robot Ethics Challenge
Open Source Project: High Level Logic (HLL)