A new way to define systems of systems?

I have recently been playing around with what I think is a new approach 
to defining and implementing distributed embedded systems. I've come up 
with a language that I call SMIL that defines the data flow between 
between the systems in a high level way.

This project is in a very preliminary state. I have used it to define 
interactions between a Linux system and an Altera NiosII based system 
running eCos using TCP/IP socket communications.

SMIL generates all the socket related code to make the communication 
possible based on the data flow definitions that you provide.

SMIL can also generate code for state machines based on the data flow 
definitions.

The reason that I'm posting is that I'd like to see if there is any 
interest in this approach (beyond just me). A very preliminary document 
exists at http://pennington.ms/SMIL.pdf

If this approach seems reasonable my plan is to extend SMIL to generate 
code for different communication paths, e.g. UDP, CAN, serial, etc. I'd 
also like to generate VHDL code for portions of the system specified by 
the user where top performance is required.

Right now, SMIL supports Linux and eCos based systems. If there is 
interest I plan to support at least vxWorks and uC/OS-II in the future.

Be gentle. This is an open source project in its very early stages. If 
there is enough interest I'll work on making a release for general 
distribution.

-Rich

On Apr 7, 8:47 am, Richard Pennington <r...@pennware.com> wrote:

> with a language that I call SMIL that defines the data flow between
> between the systems in a high level way.

You might want to think of a new name :) <http://www.w3.org/AudioVideo/
>

larwe wrote:
> On Apr 7, 8:47 am, Richard Pennington <r...@pennware.com> wrote:
> 
>> with a language that I call SMIL that defines the data flow between
>> between the systems in a high level way.
> 
> You might want to think of a new name :) <http://www.w3.org/AudioVideo/
> 

Yes. Too bad. I kind of liked SMIL.

-Rich

On Apr 7, 9:40 am, Richard Pennington <r...@pennware.com> wrote:

> Yes. Too bad. I kind of liked SMIL.

At this point, I believe all pronounceable acronyms up to and
including four letters long are taken.

You might want to take a look at telegraph shorthand codebooks from
the nineteenth and early twentieth century. Businesses frequently used
such codebooks to reduce costs of sending a telegram. Words that could
be read aloud were cheaper than random combinations of letters; hence
there were published large codebooks of pronounceable non-words.

Richard Pennington wrote:

> I have recently been playing around with what I think is a new approach
> to defining and implementing distributed embedded systems. I've come up
> with a language that I call SMIL that defines the data flow between
> between the systems in a high level way.

When you opened this thread I got interested but it seems your idea of high
level is up to the point where I would start in with psuedo-code in Forth.
High level definition of systems tends, in my mind, to be like the Hatley
and Pirbhai structured design methods. Useful for being able to be
inclusive of the human elements of a system as well.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Paul E. Bennett wrote:
> Richard Pennington wrote:
> 
>> I have recently been playing around with what I think is a new approach
>> to defining and implementing distributed embedded systems. I've come up
>> with a language that I call SMIL that defines the data flow between
>> between the systems in a high level way.
> 
> When you opened this thread I got interested but it seems your idea of high
> level is up to the point where I would start in with psuedo-code in Forth.
> High level definition of systems tends, in my mind, to be like the Hatley
> and Pirbhai structured design methods. Useful for being able to be
> inclusive of the human elements of a system as well.
> 

Actually what I'm trying to do is to solve a problem that I have seen 
often in the past and for which I have seen no good solution. I wanted 
to model the data flow between systems that make up a complete system. 
But more importantly, I wanted to be able to generate code that 
implemented the model directly.

Often, communication between systems is represented at a very low level. 
I've tried to turn that upside down and make the communication 
definition occur at a higher level. SMIL is very much like your Forth 
pseudo code, I suppose, except that it isn't pseudo code. It is 
translated into C and then executed directly.

SMIL (or whatever this thing's name becomes) is a work in progress. Or 
maybe just an idea that won't go anywhere. I appreciate the fact that 
you took the time to look at it.

-Rich

On Apr 8, 8:06 am, Richard Pennington <r...@pennware.com> wrote:
> Paul E. Bennett wrote:
> > Richard Pennington wrote:
>
> >> I have recently been playing around with what I think is a new approach
> >> to defining and implementing distributed embedded systems. I've come up
> >> with a language that I call SMIL that defines the data flow between
> >> between the systems in a high level way.
>
> > When you opened this thread I got interested but it seems your idea of high
> > level is up to the point where I would start in with psuedo-code in Forth.
> > High level definition of systems tends, in my mind, to be like the Hatley
> > and Pirbhai structured design methods. Useful for being able to be
> > inclusive of the human elements of a system as well.
>
> Actually what I'm trying to do is to solve a problem that I have seen
> often in the past and for which I have seen no good solution. I wanted
> to model the data flow between systems that make up a complete system.
> But more importantly, I wanted to be able to generate code that
> implemented the model directly.
>
> Often, communication between systems is represented at a very low level.
> I've tried to turn that upside down and make the communication
> definition occur at a higher level. SMIL is very much like your Forth
> pseudo code, I suppose, except that it isn't pseudo code. It is
> translated into C and then executed directly.
>
> SMIL (or whatever this thing's name becomes) is a work in progress. Or
> maybe just an idea that won't go anywhere. I appreciate the fact that
> you took the time to look at it.
>
> -Rich

Your goal is definitely intriguing.  But there are a couple of things
that I am not sure of -

1. In a distributed environment, you do not want centralized control.
Therefore, the only thing standard between the two devices is the
interface.  So a unified tool to describe the devices seems kind of
skewed from the basis.

2. If a goal of SMIL is to describe an interface and then generate any
logic for it straight from C.  Isn't this one of the goals of SystemC?

Am I missing something?
Best regards,
Sanjay

Richard Pennington wrote:
 
> Actually what I'm trying to do is to solve a problem that I have seen
> often in the past and for which I have seen no good solution. I wanted
> to model the data flow between systems that make up a complete system.
> But more importantly, I wanted to be able to generate code that
> implemented the model directly.

Which is what the Hatley & Pirbhai Structured Design methods were intended
to do with the exception of the code generation part. Then some of the UML
style modeling tools take over from there as I understand it (although I
have never used them).
 
> Often, communication between systems is represented at a very low level.

Considering that I have seen communications between systems modelled at
various levels I think that your use of the term often is hardly
applicable.

> I've tried to turn that upside down and make the communication
> definition occur at a higher level. SMIL is very much like your Forth
> pseudo code, I suppose, except that it isn't pseudo code. It is
> translated into C and then executed directly.

Forth psuedo code can, with little effort, be translated into working Forth
based systems. It is only a short step to make from there. The other
modeling is often at a higher level of abstraction and is more useful when
speaking to clients about their requirements.
 
> SMIL (or whatever this thing's name becomes) is a work in progress. Or
> maybe just an idea that won't go anywhere. I appreciate the fact that
> you took the time to look at it.

As I said, the initial post raised my interest but the linked document
dashed any other notions about techniques that may be more useful than what
I am currently using at any level.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

fpgabuilder wrote:
[snip]
> 
> Your goal is definitely intriguing.  But there are a couple of things
> that I am not sure of -
> 
> 1. In a distributed environment, you do not want centralized control.
> Therefore, the only thing standard between the two devices is the
> interface.  So a unified tool to describe the devices seems kind of
> skewed from the basis.
> 
> 2. If a goal of SMIL is to describe an interface and then generate any
> logic for it straight from C.  Isn't this one of the goals of SystemC?
> 
> Am I missing something?
> Best regards,
> Sanjay
> 

Great questions. Part of my problem is explaining what I'm trying to 
accomplish, I think.

A little background. In my day job I work on a fairly complex medical 
device that is made up of an operator's console and image reconstruction 
  system that is Linux based. This connects to the actual patient 
scanner via an ethernet connection to an SBC running vxWorks. Part of 
the system rotates about an axis and has its own SBC running vxWorks. 
Both the stationary and rotating sides of the device talk to a variety 
of other subsystems via Ethernet, CAN, and serial ports.

The interfaces between the systems are currently described with C header 
files. A lot of code is present on the two SBCs to translate the TCP/IP 
messages coming from the operators console to forms compatible with the 
non-Ethernet communication links.

SMIL is an attempt to unify the definition of the communication paths 
throughout the entire system. It is designed for distributed computing 
but my emphasis has been on systems of the sort I just described. Pats 
might come up and go down asynchronously, but generally most of the 
parts need to be present for the device to function.

I wanted to be able to do semantic checks on the interfaces. SMIL will 
check that a data packet (a SMIL event) which is generated in a part of 
the system is consumed in another part of the system, for example. In 
general events are broadcast in SMIL: You don't have to explicitly say 
where the event is being consumed. This decouples the system to a great 
extent, obviously, making for what I think is a cleaner system design. 
SMIL doesn't really do broadcasts, however. During system generation it 
can see where events flow and generate code to send the events from the 
source to the destination(s) automatically.

As to point two, Yes, SystemC can generate code for FPGAs. SMIL's main 
emphasis is the communication paths between the systems. To that end 
there are facilities to detect when subsystems power up and go down, 
trace events, do endian conversions, etc. that are not (I think) 
directly available in SystemC. Also, SMIL is (or will be) open source. I 
don't believe that's true of SystemC.

Thanks for the questions.

-Rich

Richard Pennington <rich@pennware.com> wrote:

>fpgabuilder wrote:
>[snip]
>> 
>> Your goal is definitely intriguing.  But there are a couple of things
>> that I am not sure of -
>> 
>> 1. In a distributed environment, you do not want centralized control.
>> Therefore, the only thing standard between the two devices is the
>> interface.  So a unified tool to describe the devices seems kind of
>> skewed from the basis.
>> 
>> 2. If a goal of SMIL is to describe an interface and then generate any
>> logic for it straight from C.  Isn't this one of the goals of SystemC?
>> 
>> Am I missing something?
>> Best regards,
>> Sanjay
>> 
>
>Great questions. Part of my problem is explaining what I'm trying to 
>accomplish, I think.
>
>A little background. In my day job I work on a fairly complex medical 
>device that is made up of an operator's console and image reconstruction 
>  system that is Linux based. This connects to the actual patient 
>scanner via an ethernet connection to an SBC running vxWorks. Part of 
>the system rotates about an axis and has its own SBC running vxWorks. 
>Both the stationary and rotating sides of the device talk to a variety 
>of other subsystems via Ethernet, CAN, and serial ports.
>
>The interfaces between the systems are currently described with C header 
>files. A lot of code is present on the two SBCs to translate the TCP/IP 
>messages coming from the operators console to forms compatible with the 
>non-Ethernet communication links.
>
>SMIL is an attempt to unify the definition of the communication paths 
>throughout the entire system. It is designed for distributed computing 
>but my emphasis has been on systems of the sort I just described. Pats 
>might come up and go down asynchronously, but generally most of the 
>parts need to be present for the device to function.
>
>I wanted to be able to do semantic checks on the interfaces. SMIL will 
>check that a data packet (a SMIL event) which is generated in a part of 
>the system is consumed in another part of the system, for example. In 
>general events are broadcast in SMIL: You don't have to explicitly say 
>where the event is being consumed. This decouples the system to a great 
>extent, obviously, making for what I think is a cleaner system design. 
>SMIL doesn't really do broadcasts, however. During system generation it 
>can see where events flow and generate code to send the events from the 
>source to the destination(s) automatically.
>
>As to point two, Yes, SystemC can generate code for FPGAs. SMIL's main 
>emphasis is the communication paths between the systems. To that end 
>there are facilities to detect when subsystems power up and go down, 
>trace events, do endian conversions, etc. that are not (I think) 
>directly available in SystemC. Also, SMIL is (or will be) open source. I 
>don't believe that's true of SystemC.
>

Just a question out of curiosity: Are you familiar with 'Strategies
for real-time system specification' written by Hatley and Pirbhai?

The book basically describes a method with which you can link and
verify data flows together with the state changes in a complex system.


The only thing that worries me is: yet another language... Can't you
make the SMIL language fit inside the C-like syntax? This makes it a
lot easier to get started with (see the succes of Java, C# and PHP).
It would also be a lot easier get a parser (don't forget the
pre-processor for includes, conditional compilation and defines!).

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl