Standardizing digital, analog control points in the kernel?

[Brian McGovern (bmcgover)]

>________________________________________
>From: Michael B. Eichorn [ike at michaeleichorn.com]
>Sent: Wednesday, December 16, 2015 5:48 PM
>To: Brian McGovern (bmcgover); freebsd-questions at freebsd.org
>Subject: Re: Standardizing digital, analog control points in the kernel?
>
>On Wed, 2015-12-16 at 20:58 +0000, Brian McGovern (bmcgover) wrote:
>> All,
>>   This is a question that I'm sure could span multiple lists and
>> multiple perspectives; for example, there is probably significant
>> input to be had from -arm. However, I'm going to ask here to try to
>> get the biggest collection of feedback.
>>
>>   I've been working with a number of I/O capable devices for awhile -
>> Pis, Beaglebones, for example, but also a lot of the USB Velleman
>> boards, X-10, Insteon, etc.
>>
>>   I've been contemplating a project to consolidate the various
>> control points, with a certain amount of metadata, at the userland
>> level and provide a standardized interface - most likely through a
>> network socket via XML, some form of HTTP, a combination, or
>> something else entirely. The reason would be to sufficiently abstract
>> the various layers so that domain experts could focus on specific
>> areas - for example, device driver writers could focus on adding more
>> devices which provide control points without needing to provide
>> server or applications bits, UI writers and control applications can
>> worry about looking pretty and communicating through a language-
>> independent interface, and so forth.
>>
>>   The question I have is whether a.) Anyone is looking at doing
>> something similar, and b.) if anyone is looking at doing something
>> similar inside the kernel as a device driver, filesystem, or other
>> variation (e.g. I'm thinking of something like ucom, where the low-
>> level hardware drivers plug in to it to provide a generic user
>> interface on top)?
>>
>>      -B
>
>This is an interesting idea and I think that a unified method for
>handling I/O would be very useful. It sounds like you are mostly
>talking about maker, home automation, and internet-of-things type devices, but it might have applications for scientific data acquisition and industrial control as well.

>Also such a stack should support realtime computing. Interestingly it
>appears that RTLinux died in 2011 so this could be an advantage for
>FreeBSD in IoT and Maker devices. Realtime is, in my opinion as a
>mechanical engineer, essential for any system that might control an
>appliance/drone/robot, or for that matter data acquisition in general.
>
>That said, I do like the idea of separating the application logic and
>the gui out from the details of the individual devices being used.

My commercial work experience in the space was commercial building automation via Andover Controls devices back in the late 80s/early 90s (Andover has since been acquired by Schnider electric) which ran over BACnet.

What I'm hoping to do as the primary goal of my work is to define a network layer protocol for the data exchage. That way, if drivers and userland vary on FreeBSD vs. Linux vs. fill-in-another-OS, it theoretically doesn't matter - a Linux based UI should be able to control a protocol compliant Raspbian system, or a FreeBSD box. Similarly, if you want to use C, or C++, or Python, or Java, or fill-in-another-language to connect to the network and chat with a device, it doesn't matter. At the end of the day, users should be able to select best-in-class for the various layers, and plug it together.

In designing, I'm stuck at the point of having a fairly common layer pointing at the network, and bolt-on "device drivers" for the various flavors of I/O. For example, the Beaglebone ADC has a driver which operates via sysctl(); the digital pins use GPIO. Vellemen USB boards, X-10, and Insteon interfaces are basically USB serial streams, each with their own proprietary command/response protocols.

Hence, as a secondary goal, I'm curious to explore setting up a common frame work for the typical types of I/O one typically sees in this space - Digital I/O, Analog I/O, potentially things like driver enforced tri-state.

In terms of "Real Time", I dislike the term mostly because it becomes terribly abused to mean what the engineer wants it to mean. Using the definition of "of or relating to a system in which input data is processed within milliseconds so that it is available virtually immediately as feedback, e.g., in a missile guidance or airline booking system." (Google definition, should you want to trace my steps), its not impossible, but its well outside the scope. Most operating systems have large, asynchronous components, and the network will have all kinds of random variations on timing. Unless you managed everything on and off the wire, you may get that kind of response most of the time, maybe even every time, but I doubt it'll be warrantied.

Further, "correct" systems have to have other considerations - power on states, loss-of-control failsafes, and so on, most of which are either above or below the layer interfaces.

  -B