Author Archive

SCDL and Web Services

My Dad has been having fun hacking with single-board computers and has been sending me a lot of links. This review of the of the Raspberry Pi Model A looks interesting: A quick Model A show and tell from Adafruit

I spent years working as an embedded systems engineer and have a love of these small and inexpensive single-board computers. As a side note my Leap Motion Leap should arrive soon and I want to try connecting it to a Raspberry Pi for some recreational hacking.

The general idea is that I would use a small HTTP server on the Raspberry Pi to communicate with a fancy-pants HTML5 application running in the browser to monitor the Leap and control routing of Leap data out to various other peripheral devices connected to the Raspberry Pi. The details aren’t important. But what is interesting is how I think I can leverage SCDL in this project.

Soft Circuit Description Language  (SCDL) is a JSON object model for “soft circuits.” Soft circuits are system design artifacts conceptually analogous to digital circuit schematics.

As SCDL is JSON you can send it around conveniently. Maybe you have a web service API defined on your embedded web server that accepts a SCDL JSON parameter as input for example. Now consider what our little embedded web service might do with the SCDL it just received.

Recalling that SCDL is used to model program specifications, one particularly interesting thing our little embedded web server might do is transform the program specification into something it can actually execute, execute it, and return the results of the program execution to the caller as the request response.

Let that sink in for a minute. We just defined a single trivial web service API that can be implemented with widely available technology that effectively eliminates application logic as we know from the server (client too but we’ll get to that).

Rather than server-side routing tables and lots of carefully written routines here and there, we have a single simple web service that will essentially re-wire itself dynamically to service requests.

We can apply the same logic to the client as well and application logic as we know it starts to magically evaporate. Yet the functionality remains. There’s actually no magic. Just some clever factoring. But it’s weird. So let’s dig a bit deeper.

Think of a JSON-encoded SCDL message sent from point A to point B as a request and response protocol.

Request input comprises: a SCDL catalogue in JSON format, optionally some other JSON-encoded data objects that will be used as input to the program described by the SCDL catalogue.

Request output comprises: a JSON string (possibly containing another SCDL catalogue to be processed by the caller).

Bringing this back to the Raspberry Pi and our little embedded web server example, consider that upon receipt of a SCDL catalogue from the client, the embedded webserver unpacks the SCDL and uses the “soft circuit” schematic diagram it represents to:

  • instantiate the described program using a library of native plug-ins installed on the Raspberry Pi
  • “execute” this program (effectively a dynamically created web service)
  • return the results to the caller in JSON format (data + possibly more SCDL…)

Here the simple web service has absolutely no idea what the semantics of the request are.

And, this is why I say that there’s no hard-wired application logic on the server. In fact there is application logic on the server. It’s just expressed in a very pure and compact.

Our server-side deployment consists of (a) a collection of  low-level plug-ins and (b) a SCDL catalogue that specifies the “parts” that a client can use in a “soft circuit” to form a request.

In essence, this static SCDL catalogue is your application logic. It defines a grammar of possible requests and maps each to a concrete web service, built on-the-fly, via program transformation.

I like this idea because I’m lazy. I don’t want to figure out how to talk to my Leap device when it’s plugged into the USB port on my Raspberry Pi.

Rather, I want to browse a catalogue of Leap modules, select one for Raspberry Pi, stick it in my deployment package, and then expose it via my server’s SCDL catalogue. That way if a client wants to open a web socket to read a live telemetry stream of Leap data, it can send the server a SCDL request containing a little “soft circuit” that connects the Leap module to a web socket module.

Client-side, I’ve got the server’s SCDL catalog. I see the server has a Leap module and a web socket module and I know that the server knows how to connect the two somehow. I also know how I can ask the server to connect the these two resources for me.

We’ll come back to this topic later. That’s enough to think about for today :)

LEGO Workers and Chips

LEGO workers and IC's

Ha. I love this!

SCDL Visualization and Editing Ideas

Soft Circuit Description Language (SCDL) draws its core concepts from digital circuit schematics and defines a schema for serializing the following entities to JSON format:

  • virtual software “cores” – small, re-usable Turing Machine models
  • virtual software “chips” – re-usable system specification assemblies comprising any number of “cores” and/or “chips” wired together.
  • virtual software “circuits” – an abstract blueprint for building a software program.

The HTML5 SCDL editor I’m working on leverages D3js for data visualization (and some interaction). I am hugely inspired by this library.

Some ideas:


Relational input & graph building:

SCDL model hierarchy navigation:

SCDL interconnection topology:

SCDL entity interaction:

SCDL core transition matrix:

Simulation and test results:

Rebooting Encpasule Project for the Web

Repost from:

Welcome to the Encapsule Project.

The Encapsule Project is an open source effort to apply electrical engineering design and modeling techniques to software development.

Quick update:

I’ve been working to re-imagine the Hyperworx prototype, or at least it’s core concepts, using modern web technologies and am preparing to launch a new single-page HTML5 called “schema” that implements an interactive data visualization and editing environment for working with JSON-encoded Soft Circuit Description Language (SDCL (pronounced “scuddle“)) models.

Briefly, “soft circuits” are the software analogue of a digital circuit board schematics. Just as a digital circuit board schematic captures the essence of a system design to be realized in hardware, a “soft circuit” schematic captures the essence of a system design to be realized in software. Given this, SCDL is a JSON serialization dialect for exchanging “soft circuit” schematics across the Internet.

So what do you do with a “software schematic” that is machine-readable? There are a lot of possibilities. But first, we need some SCDL to fuddle with…

SCDL models are cool:

  • SCDL is based fundamentally on Turing Machine models.
  • SCDL can be used to model any system regardless of its scale.
  • SCDL is not tied to a hardware platform, operating system, or programming language.
  • SCDL is not actually even tied to software: it can be used to model hierarchical systems in any domain (although we’re primarily interested in its application to the software domain here).

SCDL is transformative:

SCDL models are machine-readable abstract system specifications which are exactly what’s required to write a software program that transforms SCDL into an executable runtime that implements your design given a binding to a specific target runtime environment.

For example, it would be possible to write a “transformer” that converts SCDL into a C++ program, or creates a single-page HTML5 application that performs the “transformation” on the client by operating directly on the SCDL JSON.Or, on the server via node.js. Or, all of the above. Maybe we want to model our entire cloud-based enterprise in SCDL and “transform” the clients, custom back-end servers that execute app logic on metal, and everything that glues it all together.

The possibilities are endlessly cool. Please stay tune for updates. The SCDL editor is coming soon!

– Chris

Deprecated to ‘Junk':


Publication Plan, Dependency Questions, License Model

I spent some time back in late February / March working to revive the prototype code from 2004 (the last time I actually looked at the source code) but stopped short of a total bring-up thinking that the time would be better spent on refactoring routines that I now feel are poorly implemented (who wrote this crap?) and porting sections dependent on the Windows OS (see Welcome post).

The prototype codebase has the following dependencies currently:

Obviously quite a lot has changed since 2004. Notwithstanding, investment in STL and Boost in particular seem to have withstood the test of time.

As I’m super busy currently, getting the source code published is going to take some time because I do not want to release the currently busted and out-of-date source as a baseline. It will simply be too confusing and chaotic. What’s likely is that as I tackle the various subsystems of the platform (there are ~six major subsystems) that I’ll package them as libraries and release them one at a time. The first will likely be the base parsers that read and deserialize the XML-encoded data flow graphs upon which the entire platform is based.

Source code will eventually appear on GitHub where I’ve a created the Encapsule-Project organization (no repositories currently so don’t even bother looking).

License model: I intend to publish under the Boost Software License because it is simple, permissive, and non-controversial. I could say more but the explanation would then exceed the number of words in the actual license text.

I would appreciate hearing from anyone willing to offer suggestions about the list items above marked ‘under investigation’ and more broadly from people who have practical ideas for applying this work to the problems they’re facing. Or, if you think the whole effort is a total waste of time I would like to hear that too :)

Thanks, Chris

Welcome to the Encapsule Project

Started in 2001, the Encapsule Project was at one point a commercial undertaking of my start-up Encapsule Systems, Inc. My partners and I failed to get the company funded and pulled the plug in 2004 and we all went on to do other things.

Until now little information about this project has been published publicly. I am now starting to publish details in hopes of generating interest in this work.

I’ve created two pages on this blog to start this process:

Subsequent posts will discuss my future plans for this project. Briefly:

  • Release the entire 170K+ lines of C++ that comprise the prototype codebase as open source.
  • Update portions of the codebase to leverage newly standardized extensions to the STL (TR1).
  • Carefully review and update significant dependencies on the Boost C++ libraries.
  • Port the Windows platform-specific sections of the code to Linux (or possibly just leverage Qt).
  • Port the Windows platform-specific user interface to Qt.
  • Explore options for enabling plug-ins to be written in dynamic languages (e.g. Python).
  • Build a community comprised of core contributors, plug-in and model authors, and end users of the platform (this could be people who snap together applications/services using other people’s models, or other projects that wish to embed the core runtime controller).
  • Find corporate sponsorship for this effort?

Thanks, Chris