You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Łukasz Dywicki <lu...@code-house.org> on 2020/08/25 23:11:22 UTC
Protocol encapsulation
I come to a point where I need to brainstorm a little bit.
I started my inspection of CANopen and it looks like a whole new thing
which is built on top of CAN. What's worth to remember is fact that
CANbus has many flavors and transport layer can be pretty much anything.
Anything means serial interface (slcan), socketcan, udp (can over
ethernet), wrapping in other transports such as ethercat to end with
vendor specific interfaces and SDKs.
All above result in creation of CAN frames in slightly different
formats. All above interfaces obviously follow all rules which are
relevant for CAN.
Two versions of CAN frame which are standardized are:
- CAN 2.0A with 11 bit identifier and maximum 8 bytes of data - called
sometimes standard frame format (SFF)
- CAN 2.0B using 29 bit sometimes called extended frame format (EFF)
On the bus level EFF identifier is split into 11 bits and then 18 bits.
Data length is also 8 bytes max.
- CAN FD - not entirely clear on identifiers for me, but it allows up to
64 bytes of data. Most of modern cars already uses it.
Reason why I enlist all above is to show you the rich set of transport
options which we did not experience for PLCs so far. Most of protocols
we have so far is bound to one or maximum two transports.
In this case we have standard physical layer, different frames,
different interfaces yet all should lead rather to an unified result.
The CANopen mentioned early in this mail defines OSI layers which could
be seen seen as network, transport, session and application layer.
CANopen is not the only one attempt to standardize payloads, there are
others which are dedicated to narrow areas where standard is used.
Implementation of CANopen has one challenge upfront - it divides 11 bit
identifier into 4 bit function code and 7 bit node identifier. There are
also some attempts to make use of CAN 2.0B/EFF identifiers there,
however my knowledge about that is currently fairly limited.
Problem which I face now is impossibility to implement CANopen without
relying on a specific transport. Given that we have many, multiplied at
some point of time by various frame encoding formats 2.0B/CAN FD we will
quickly end in the most over-bloated CAN interface ever found.
This brings me to following finding for CAN. We have a clear indication
of application layer which is independent from transport itself:
CAN transport -> CAN 2.0A frame -> CANopen
Now in order to realize above we need few things. First of all - I would
say we need to re-parse part of lower layer contents into something new.
It is quite opposite to what we know from IP where everything build
above layer 3 doesn't care about MAC/network layer at all. CANopen do
care, cause it requires access to identifier in order to determine
function code.
I been thinking how we could arrange that. One idea I got so far is
re-wrapping of read buffer and its sections to re-parse it. Second
option I see is sticking to pre-defined CAN frame format.
While socketcan looks like an natural selection for later option it
seems that there is some legitimate reason why so many interface
manufacturers still offer their own APIs to access bus. Forcing longer
than necessary identifiers might also hurt C and embedded stuff Chris is
working on. After all encoding of CAN 2.0A identifiers in 32 bit memory
block takes almost 3 times more than it actually needs.
Looking forward to your comments and opinions.
Cheers,
Łukasz
Re: Protocol encapsulation
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey folks, replies inline.
Am 26.08.20, 04:38 schrieb "Otto Fowler" <ot...@gmail.com>:
>
> I would rather have multiple, clean drivers than one that is so
> complicated myself.
> Maybe if there was a way to structure the mspec’s such that you could
> re-use or re-combine them ( ie have multiple mspecs that in some
> combinations generate different drivers ).
I agree that having dedicated mspecs makes a ton of sense, cause when
anything breaks you know there is only one faulty place. When multiple
layers are involved things get complicated.
On other hand amount of duplicated code and structures will make it
impossible to maintain canopen integration in good shape. If we will
implement it on top of socketcan and slcan (or any other transport)
quite big chunk related to application layer will end up duplicated.
Maybe I am thinking too much ahead, cause we don't even have working
socketcan+canopen. I just try to avoid unnecessary rearrangements in
near future if we can and if all we need is, let say #include statement
in mspec I'm here to not only listen but eventually do. :) [you already
know that my commitment is eventually (in-)consistent]
On 26.08.2020 10:25, Christofer Dutz wrote:
> I think this fits well into the problem I was having with ADS.
>
> Right now the ADS driver will only support TCP, even if most of the stuff is in place for serial.
>
> The reason is that in order to use the serial transport a different base-type and transport-level-logic is needed than for TCP.
>
> What I was proposing, was to have the option to provide different layer-2 (2 because it's lower than 3 not because it's actually layer 2 in the ISO model) transport logic depending on the transport being used.
>
> Protocols that support encapsulation of other protocols (like EtherCAT) could then also provide dedicated transport modules which other protocols could use.
>
> So something like: can-open:ethercat://????????? Could possibly be implemented.
>
> Chris
This is very good point. I do expect that in case of ethercat we will
face situation where can/canopen frame is packed into data section of
ethercat frame, hence we will need to follow transport rules valid for
ethercat, but parse actual frame blob payloads according to can.
Details on this will obviously require further work on any transport
which supports encapsulation. Rather not in near future.
Anyhow, I will try getting the canopen with socketcan first and see how
much work its gonna cost to switch it to slcan. Based on that we'll be
able to estimate investment costs for any of above.
Best regards,
Łukasz
>
>
>
> Am 26.08.20, 04:38 schrieb "Otto Fowler" <ot...@gmail.com>:
>
> I would rather have multiple, clean drivers than one that is so
> complicated myself.
> Maybe if there was a way to structure the mspec’s such that you could
> re-use or re-combine them ( ie have multiple mspecs that in some
> combinations generate different drivers ).
>
>
>
> On August 25, 2020 at 19:11:34, Łukasz Dywicki (luke@code-house.org) wrote:
>
> I come to a point where I need to brainstorm a little bit.
>
> I started my inspection of CANopen and it looks like a whole new thing
> which is built on top of CAN. What's worth to remember is fact that
> CANbus has many flavors and transport layer can be pretty much anything.
> Anything means serial interface (slcan), socketcan, udp (can over
> ethernet), wrapping in other transports such as ethercat to end with
> vendor specific interfaces and SDKs.
> All above result in creation of CAN frames in slightly different
> formats. All above interfaces obviously follow all rules which are
> relevant for CAN.
>
> Two versions of CAN frame which are standardized are:
> - CAN 2.0A with 11 bit identifier and maximum 8 bytes of data - called
> sometimes standard frame format (SFF)
> - CAN 2.0B using 29 bit sometimes called extended frame format (EFF)
> On the bus level EFF identifier is split into 11 bits and then 18 bits.
> Data length is also 8 bytes max.
> - CAN FD - not entirely clear on identifiers for me, but it allows up to
> 64 bytes of data. Most of modern cars already uses it.
>
> Reason why I enlist all above is to show you the rich set of transport
> options which we did not experience for PLCs so far. Most of protocols
> we have so far is bound to one or maximum two transports.
> In this case we have standard physical layer, different frames,
> different interfaces yet all should lead rather to an unified result.
> The CANopen mentioned early in this mail defines OSI layers which could
> be seen seen as network, transport, session and application layer.
> CANopen is not the only one attempt to standardize payloads, there are
> others which are dedicated to narrow areas where standard is used.
>
> Implementation of CANopen has one challenge upfront - it divides 11 bit
> identifier into 4 bit function code and 7 bit node identifier. There are
> also some attempts to make use of CAN 2.0B/EFF identifiers there,
> however my knowledge about that is currently fairly limited.
> Problem which I face now is impossibility to implement CANopen without
> relying on a specific transport. Given that we have many, multiplied at
> some point of time by various frame encoding formats 2.0B/CAN FD we will
> quickly end in the most over-bloated CAN interface ever found.
>
> This brings me to following finding for CAN. We have a clear indication
> of application layer which is independent from transport itself:
> CAN transport -> CAN 2.0A frame -> CANopen
>
> Now in order to realize above we need few things. First of all - I would
> say we need to re-parse part of lower layer contents into something new.
> It is quite opposite to what we know from IP where everything build
> above layer 3 doesn't care about MAC/network layer at all. CANopen do
> care, cause it requires access to identifier in order to determine
> function code.
> I been thinking how we could arrange that. One idea I got so far is
> re-wrapping of read buffer and its sections to re-parse it. Second
> option I see is sticking to pre-defined CAN frame format.
> While socketcan looks like an natural selection for later option it
> seems that there is some legitimate reason why so many interface
> manufacturers still offer their own APIs to access bus. Forcing longer
> than necessary identifiers might also hurt C and embedded stuff Chris is
> working on. After all encoding of CAN 2.0A identifiers in 32 bit memory
> block takes almost 3 times more than it actually needs.
>
> Looking forward to your comments and opinions.
>
> Cheers,
> Łukasz
>
Re: Protocol encapsulation
Posted by Christofer Dutz <ch...@c-ware.de>.
I think this fits well into the problem I was having with ADS.
Right now the ADS driver will only support TCP, even if most of the stuff is in place for serial.
The reason is that in order to use the serial transport a different base-type and transport-level-logic is needed than for TCP.
What I was proposing, was to have the option to provide different layer-2 (2 because it's lower than 3 not because it's actually layer 2 in the ISO model) transport logic depending on the transport being used.
Protocols that support encapsulation of other protocols (like EtherCAT) could then also provide dedicated transport modules which other protocols could use.
So something like: can-open:ethercat://????????? Could possibly be implemented.
Chris
Am 26.08.20, 04:38 schrieb "Otto Fowler" <ot...@gmail.com>:
I would rather have multiple, clean drivers than one that is so
complicated myself.
Maybe if there was a way to structure the mspec’s such that you could
re-use or re-combine them ( ie have multiple mspecs that in some
combinations generate different drivers ).
On August 25, 2020 at 19:11:34, Łukasz Dywicki (luke@code-house.org) wrote:
I come to a point where I need to brainstorm a little bit.
I started my inspection of CANopen and it looks like a whole new thing
which is built on top of CAN. What's worth to remember is fact that
CANbus has many flavors and transport layer can be pretty much anything.
Anything means serial interface (slcan), socketcan, udp (can over
ethernet), wrapping in other transports such as ethercat to end with
vendor specific interfaces and SDKs.
All above result in creation of CAN frames in slightly different
formats. All above interfaces obviously follow all rules which are
relevant for CAN.
Two versions of CAN frame which are standardized are:
- CAN 2.0A with 11 bit identifier and maximum 8 bytes of data - called
sometimes standard frame format (SFF)
- CAN 2.0B using 29 bit sometimes called extended frame format (EFF)
On the bus level EFF identifier is split into 11 bits and then 18 bits.
Data length is also 8 bytes max.
- CAN FD - not entirely clear on identifiers for me, but it allows up to
64 bytes of data. Most of modern cars already uses it.
Reason why I enlist all above is to show you the rich set of transport
options which we did not experience for PLCs so far. Most of protocols
we have so far is bound to one or maximum two transports.
In this case we have standard physical layer, different frames,
different interfaces yet all should lead rather to an unified result.
The CANopen mentioned early in this mail defines OSI layers which could
be seen seen as network, transport, session and application layer.
CANopen is not the only one attempt to standardize payloads, there are
others which are dedicated to narrow areas where standard is used.
Implementation of CANopen has one challenge upfront - it divides 11 bit
identifier into 4 bit function code and 7 bit node identifier. There are
also some attempts to make use of CAN 2.0B/EFF identifiers there,
however my knowledge about that is currently fairly limited.
Problem which I face now is impossibility to implement CANopen without
relying on a specific transport. Given that we have many, multiplied at
some point of time by various frame encoding formats 2.0B/CAN FD we will
quickly end in the most over-bloated CAN interface ever found.
This brings me to following finding for CAN. We have a clear indication
of application layer which is independent from transport itself:
CAN transport -> CAN 2.0A frame -> CANopen
Now in order to realize above we need few things. First of all - I would
say we need to re-parse part of lower layer contents into something new.
It is quite opposite to what we know from IP where everything build
above layer 3 doesn't care about MAC/network layer at all. CANopen do
care, cause it requires access to identifier in order to determine
function code.
I been thinking how we could arrange that. One idea I got so far is
re-wrapping of read buffer and its sections to re-parse it. Second
option I see is sticking to pre-defined CAN frame format.
While socketcan looks like an natural selection for later option it
seems that there is some legitimate reason why so many interface
manufacturers still offer their own APIs to access bus. Forcing longer
than necessary identifiers might also hurt C and embedded stuff Chris is
working on. After all encoding of CAN 2.0A identifiers in 32 bit memory
block takes almost 3 times more than it actually needs.
Looking forward to your comments and opinions.
Cheers,
Łukasz
Re: Protocol encapsulation
Posted by Otto Fowler <ot...@gmail.com>.
I would rather have multiple, clean drivers than one that is so
complicated myself.
Maybe if there was a way to structure the mspec’s such that you could
re-use or re-combine them ( ie have multiple mspecs that in some
combinations generate different drivers ).
On August 25, 2020 at 19:11:34, Łukasz Dywicki (luke@code-house.org) wrote:
I come to a point where I need to brainstorm a little bit.
I started my inspection of CANopen and it looks like a whole new thing
which is built on top of CAN. What's worth to remember is fact that
CANbus has many flavors and transport layer can be pretty much anything.
Anything means serial interface (slcan), socketcan, udp (can over
ethernet), wrapping in other transports such as ethercat to end with
vendor specific interfaces and SDKs.
All above result in creation of CAN frames in slightly different
formats. All above interfaces obviously follow all rules which are
relevant for CAN.
Two versions of CAN frame which are standardized are:
- CAN 2.0A with 11 bit identifier and maximum 8 bytes of data - called
sometimes standard frame format (SFF)
- CAN 2.0B using 29 bit sometimes called extended frame format (EFF)
On the bus level EFF identifier is split into 11 bits and then 18 bits.
Data length is also 8 bytes max.
- CAN FD - not entirely clear on identifiers for me, but it allows up to
64 bytes of data. Most of modern cars already uses it.
Reason why I enlist all above is to show you the rich set of transport
options which we did not experience for PLCs so far. Most of protocols
we have so far is bound to one or maximum two transports.
In this case we have standard physical layer, different frames,
different interfaces yet all should lead rather to an unified result.
The CANopen mentioned early in this mail defines OSI layers which could
be seen seen as network, transport, session and application layer.
CANopen is not the only one attempt to standardize payloads, there are
others which are dedicated to narrow areas where standard is used.
Implementation of CANopen has one challenge upfront - it divides 11 bit
identifier into 4 bit function code and 7 bit node identifier. There are
also some attempts to make use of CAN 2.0B/EFF identifiers there,
however my knowledge about that is currently fairly limited.
Problem which I face now is impossibility to implement CANopen without
relying on a specific transport. Given that we have many, multiplied at
some point of time by various frame encoding formats 2.0B/CAN FD we will
quickly end in the most over-bloated CAN interface ever found.
This brings me to following finding for CAN. We have a clear indication
of application layer which is independent from transport itself:
CAN transport -> CAN 2.0A frame -> CANopen
Now in order to realize above we need few things. First of all - I would
say we need to re-parse part of lower layer contents into something new.
It is quite opposite to what we know from IP where everything build
above layer 3 doesn't care about MAC/network layer at all. CANopen do
care, cause it requires access to identifier in order to determine
function code.
I been thinking how we could arrange that. One idea I got so far is
re-wrapping of read buffer and its sections to re-parse it. Second
option I see is sticking to pre-defined CAN frame format.
While socketcan looks like an natural selection for later option it
seems that there is some legitimate reason why so many interface
manufacturers still offer their own APIs to access bus. Forcing longer
than necessary identifiers might also hurt C and embedded stuff Chris is
working on. After all encoding of CAN 2.0A identifiers in 32 bit memory
block takes almost 3 times more than it actually needs.
Looking forward to your comments and opinions.
Cheers,
Łukasz