CAN message with DLC > 8 and PIC18

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

CAN message with DLC > 8 and PIC18

Alberto Alvarez
Hello list,

I am reading that reception buffers in Microchip PIC18 devices have a max length of 8bytes, so I can not receive any message with longer DLC.

I am investigating if using a overflow bit I can reach the second part of the longer message but without progress so far.
Does anyone have experience with such devices? Do you know if it's even possible?


Kind regards


Alberto Álvarez
Reply | Threaded
Open this post in threaded view
|

Re: CAN message with DLC > 8 and PIC18

Heinz-Jürgen Oertel
Am Mittwoch, 1. Juni 2016, 10:59:49 schrieb Alberto Alvarez:

> Hello list,
>
> I am reading that reception buffers in Microchip PIC18 devices have a max
> length of 8bytes, so I can not receive any message with longer DLC.
>
> I am investigating if using a overflow bit I can reach the second part of
> the longer message but without progress so far.
> Does anyone have experience with such devices? Do you know if it's even
> possible?
>
>
> Kind regards
>
>
> Alberto Álvarez


According to the classic CAN standard ISO11898 the maximum number of payload data bytes a CAN message has is eight. And that's the way all available implementations work. They buffer only 8 bytes. You can send a message with a DLC=15 but the transceiver only has a transmit buffer of eight bytes. And you can receive the DLC 15 but receive only the max number of eight bytes.

You can look for newer CAN controllers implementing CAN FD. CAN FD allows a payload up to 64 bytes.

Regards
  Heinz
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CAN message with DLC > 8 and PIC18

Alberto Alvarez
Hi Heinz

I though it may be so, then i should redirect the question to... how to operate with "multipacket Transport" (J1939/21) because when this Message is longer I am unnable to read anything.

I will keep researching. Kind regards

Alberto Álvarez

On Wed, Jun 1, 2016 at 11:36 AM, Heinz-Jürgen Oertel <[hidden email]> wrote:
Am Mittwoch, 1. Juni 2016, 10:59:49 schrieb Alberto Alvarez:
> Hello list,
>
> I am reading that reception buffers in Microchip PIC18 devices have a max
> length of 8bytes, so I can not receive any message with longer DLC.
>
> I am investigating if using a overflow bit I can reach the second part of
> the longer message but without progress so far.
> Does anyone have experience with such devices? Do you know if it's even
> possible?
>
>
> Kind regards
>
>
> Alberto Álvarez


According to the classic CAN standard ISO11898 the maximum number of payload data bytes a CAN message has is eight. And that's the way all available implementations work. They buffer only 8 bytes. You can send a message with a DLC=15 but the transceiver only has a transmit buffer of eight bytes. And you can receive the DLC 15 but receive only the max number of eight bytes.

You can look for newer CAN controllers implementing CAN FD. CAN FD allows a payload up to 64 bytes.

Regards
  Heinz

Reply | Threaded
Open this post in threaded view
|

Re: CAN message with DLC > 8 and PIC18

Heinz-Jürgen Oertel
Am Mittwoch, 1. Juni 2016, 11:48:59 schrieb Alberto Alvarez:
> how to
> operate with "multipacket Transport" (J1939/21) because when this Message
> is longer I am unnable to read anything.



J1939 defines a transport protocol TP. It uses sequences of 8 byte messages to transfer longer data. It is defined in the Standard.
In CANopen such a transport protocol is defined as one of the SDO (service data object) protocols.

Basic introduction at
https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

If you are interested in implementing J1939, search for protocol stack providers.
You can ask me for references.

Heinz
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CAN message with DLC > 8 and PIC18

Alberto Alvarez
Hello

Very interesting information. I dully thought that having seen DLC of 10 or 12 meant a physical frame with that length.

A have no experience with multipacket on PIC microcontroller but i will keep digging to see if there is a protocol stack provider for such technology

Thank you!!

Alberto Álvarez

On Wed, Jun 1, 2016 at 12:28 PM, Heinz-Jürgen Oertel <[hidden email]> wrote:
Am Mittwoch, 1. Juni 2016, 11:48:59 schrieb Alberto Alvarez:
> how to
> operate with "multipacket Transport" (J1939/21) because when this Message
> is longer I am unnable to read anything.



J1939 defines a transport protocol TP. It uses sequences of 8 byte messages to transfer longer data. It is defined in the Standard.
In CANopen such a transport protocol is defined as one of the SDO (service data object) protocols.

Basic introduction at
https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

If you are interested in implementing J1939, search for protocol stack providers.
You can ask me for references.

Heinz

Reply | Threaded
Open this post in threaded view
|

RE: CAN message with DLC > 8 and PIC18

Albert Saenz

Hola bon dia Elisabeth,

(últimament estic tenint cers problemes amb els correus I potser el vaig esborrar sense adonar-me).

Vols dir que si el “retiro” abans tots els interessos es perdran oi?

T’ho dic per dos motius:

1)      Potser em fan falta abans... (cas típic)

2)      Si surt una cosa millor abans del any i mig tenint que les accions de Iberdrola i Inditex no van be i, veiem que és interessant i rendible una nova oportunitat, el cancel·lem i el poso tot el capital 180K€ a la nova cosa.

Contestem o truquem si us plau.

Salutacions,

Albert

 

De: [hidden email] [mailto:[hidden email]] En nombre de Alberto Alvarez
Enviado el: miércoles, 1 de junio de 2016 13:09
Para: Heinz-Jürgen Oertel
CC: [hidden email]
Asunto: Re: [CANLIST] CAN message with DLC > 8 and PIC18

 

Hello

 

Very interesting information. I dully thought that having seen DLC of 10 or 12 meant a physical frame with that length.

 

A have no experience with multipacket on PIC microcontroller but i will keep digging to see if there is a protocol stack provider for such technology

 

Thank you!!


Alberto Álvarez

 

On Wed, Jun 1, 2016 at 12:28 PM, Heinz-Jürgen Oertel <[hidden email]> wrote:

Am Mittwoch, 1. Juni 2016, 11:48:59 schrieb Alberto Alvarez:
> how to
> operate with "multipacket Transport" (J1939/21) because when this Message
> is longer I am unnable to read anything.



J1939 defines a transport protocol TP. It uses sequences of 8 byte messages to transfer longer data. It is defined in the Standard.
In CANopen such a transport protocol is defined as one of the SDO (service data object) protocols.

Basic introduction at
https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

If you are interested in implementing J1939, search for protocol stack providers.
You can ask me for references.

Heinz

 

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2016.0.7598 / Base de datos de virus: 4591/12340 - Fecha de publicación: 06/01/16

Reply | Threaded
Open this post in threaded view
|

reliable CAN connection

Peter Lauer
In reply to this post by Heinz-Jürgen Oertel
Hi,
we recently reviewed a study that showed that the reliability of a system goes down when you use one CAN bus instead of discrete connections. lets say you have 3 actuators and 3 sensors on one bus, the bus goes down, you loose all actuators and all sensors.

instead of going back to all discrete wiring, what about staying with CAN on the actuator and sensor side but have a separate CAN channel on the controller? Basically like the switch from BNC Ethernet to 10BaseT. Than only one channel can go down at a time, and you still have control over the rest.

Peter--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: reliable CAN connection

John Dammeyer
There are systems that use dual CAN systems for fault redundancy.  The Space
Shuttle used 5 computers, 4 of one type and a 5th of a different and
programmed by a different group.  I believe each control surface etc. had 3
actuators and used a voting system to determine if one of the
cumputers/actuators/sensors would be disabled.

So needless to say fault tolerance can be built into anything and it all
comes with a cost.

Generally any system is only as strong as the weakest part and a CAN bus
failure could be a weak link.  But if the system is designed to be optimal
for price/size/functionality it's unlikely you'd have multiple sensors or
actuators to do the same thing.  

Let's look at a simple example.  A multi-panel solar panel with multiple
MPPT chargers and a dual axis servo motor system that tracks the sun.  If
the CAN bus connecting it all fails then the system fails since the goal of
such a system is to optimize each charger on a solar panel to operate in
its' MPPT point for a given output voltage.

If there is a master controller and each MPPT charger was Ethernet Enabled
you could use a hub or switch and run a star network from the controller to
all the MPPT chargers.  Now the weak link is the hub and a single failure
there also takes down the system.  Or use an RS485 system with a repeater in
each MPPT Charger so data goes in but is also sent out again with the second
driver.  Disconnecting the bad unit requires a small jumper module to
connect the now separated bus.  But wait, for CAN just unplug the bad MPPT
charger.  No plug needed.

Take it one step further with CAN and bring the CAN bus into the module with
a DPDT relay controlled by the module or by a star network f wires from the
master controller.  Now you can mechanically disconnect any module without
impacting the rest of the system.  

Each of those scenarios increases the price and complexity.  In the case of
solar farms that might be useful since losing one unit isn't a big deal.
But on a system that loses the end travel limit switch because the CAN bus
failed likely loses the ability to operate anyway.   That means the CAN bus
isn't the weak point.  The missing sensor would be.

So I think a generalization that CAN bus needs to be dual or more depends
totally on the application.  Where it's needed it's already done.  Notice
many of the embedded micro-processors have dual controllers.

John Dammeyer
Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950








> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Peter Lauer
> Sent: June-04-16 8:05 AM
> To: [hidden email]
> Subject: [CANLIST] reliable CAN connection
>
>
> Hi,
> we recently reviewed a study that showed that the reliability of a system
> goes down when you use one CAN bus instead of discrete connections. lets
> say you have 3 actuators and 3 sensors on one bus, the bus goes down, you
> loose all actuators and all sensors.
>
> instead of going back to all discrete wiring, what about staying with CAN
on
> the actuator and sensor side but have a separate CAN channel on the
> controller? Basically like the switch from BNC Ethernet to 10BaseT. Than
> only one channel can go down at a time, and you still have control over
the
> rest.
>
> Peter--
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: reliable CAN connection

Peter Lauer
thanks for the quick response.
I know its possible to build more redundancy into systems. What I wanted to see if projects use CAN as a single channel to communicate with only one device, and them have  a CAN channel for each device.
In our application each device has a CAN-In (M12 male ) and an a CAN-out (M12 female), if any of these connections fails, the CANbus is down.

Peter


> On Jun 4, 2016, at 11:33 AM, John Dammeyer <[hidden email]> wrote:
>
> There are systems that use dual CAN systems for fault redundancy.  The Space
> Shuttle used 5 computers, 4 of one type and a 5th of a different and
> programmed by a different group.  I believe each control surface etc. had 3
> actuators and used a voting system to determine if one of the
> cumputers/actuators/sensors would be disabled.
>
> So needless to say fault tolerance can be built into anything and it all
> comes with a cost.
>
> Generally any system is only as strong as the weakest part and a CAN bus
> failure could be a weak link.  But if the system is designed to be optimal
> for price/size/functionality it's unlikely you'd have multiple sensors or
> actuators to do the same thing.  
>
> Let's look at a simple example.  A multi-panel solar panel with multiple
> MPPT chargers and a dual axis servo motor system that tracks the sun.  If
> the CAN bus connecting it all fails then the system fails since the goal of
> such a system is to optimize each charger on a solar panel to operate in
> its' MPPT point for a given output voltage.
>
> If there is a master controller and each MPPT charger was Ethernet Enabled
> you could use a hub or switch and run a star network from the controller to
> all the MPPT chargers.  Now the weak link is the hub and a single failure
> there also takes down the system.  Or use an RS485 system with a repeater in
> each MPPT Charger so data goes in but is also sent out again with the second
> driver.  Disconnecting the bad unit requires a small jumper module to
> connect the now separated bus.  But wait, for CAN just unplug the bad MPPT
> charger.  No plug needed.
>
> Take it one step further with CAN and bring the CAN bus into the module with
> a DPDT relay controlled by the module or by a star network f wires from the
> master controller.  Now you can mechanically disconnect any module without
> impacting the rest of the system.  
>
> Each of those scenarios increases the price and complexity.  In the case of
> solar farms that might be useful since losing one unit isn't a big deal.
> But on a system that loses the end travel limit switch because the CAN bus
> failed likely loses the ability to operate anyway.   That means the CAN bus
> isn't the weak point.  The missing sensor would be.
>
> So I think a generalization that CAN bus needs to be dual or more depends
> totally on the application.  Where it's needed it's already done.  Notice
> many of the embedded micro-processors have dual controllers.
>
> John Dammeyer
> Automation Artisans Inc.
> http://www.autoartisans.com
> Ph. 1 250 544 4950
>
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Peter Lauer
>> Sent: June-04-16 8:05 AM
>> To: [hidden email]
>> Subject: [CANLIST] reliable CAN connection
>>
>>
>> Hi,
>> we recently reviewed a study that showed that the reliability of a system
>> goes down when you use one CAN bus instead of discrete connections. lets
>> say you have 3 actuators and 3 sensors on one bus, the bus goes down, you
>> loose all actuators and all sensors.
>>
>> instead of going back to all discrete wiring, what about staying with CAN
> on
>> the actuator and sensor side but have a separate CAN channel on the
>> controller? Basically like the switch from BNC Ethernet to 10BaseT. Than
>> only one channel can go down at a time, and you still have control over
> the
>> rest.
>>
>> Peter--
>> Archives and useful links: http://groups.yahoo.com/group/CANbus
>> Subscribe and unsubscribe at www.vector.com/canlist/
>> Report any problems to <[hidden email]>
>
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: reliable CAN connection

John Dammeyer
Hi Peter,
Way back around 1992 the company I was working for used DB-9 connectors for
their CAN bus connections.  The manufacturer of the equipment had proposed a
pin assignment that had 6 of the pins dedicated to CAN, two for power/gnd
and one for shield.  

The connection in the module generally just connected the CAN_IN to the
CAN_OUT bus and to its' driver.  If the module was removed or not needed on
the bus, a DB-9 connector with the pins jumpered was plugged in its place.
Alas, this was not accepted as the CANopen DB-9 and instead a T type cabled
connector is required.

In either case, odds are your hardware just wires the CAN signals between
the two M12 connectors and the internal PC board.  Or perhaps both go to the
PC board and then are connected by traces and to the modules CAN driver.

So now it becomes a study on the probability of failure of components/solder
joints and how that impacts overall system failure likelihood.

Internally the module will not be configured as a bridge with a receiver and
transmitter like it might be for a DMX-512A lighting system with
uni-directional RS-485.  Not unless it's marketed and sold as a bridge or
repeater.  

CAN is a party line system where all nodes are all on the same bus and
everyone, including the original sender,  receives what everyone sends.  A
node that has a hard electrical failure can take down the bus.  Been there.
Seen that.  Also experience hard mechanical failures in the T connection
where there is one connector into the device from a T connection on the bus.


The first is easy to solve.  Remove each module and in your case bridge it
with a M12 to M12 cable.  If the system is alive again you've found the bad
module.

The second is harder.  We've used a TDR (Time Domain Reflectometer) to
approximate where the bus has a short or open circuit. Then mechanically
inspected the connections near the fault area.

If that doesn't answer your question perhaps you could explain the problem
differently?

John Dammeyer



> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Peter Lauer
> Sent: June-04-16 1:01 PM
> To: [hidden email]
> Subject: Re: [CANLIST] reliable CAN connection
>
>
> thanks for the quick response.
> I know its possible to build more redundancy into systems. What I wanted
> to see if projects use CAN as a single channel to communicate with only
one
> device, and them have  a CAN channel for each device.
> In our application each device has a CAN-In (M12 male ) and an a CAN-out
> (M12 female), if any of these connections fails, the CANbus is down.
>
> Peter
>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: reliable CAN connection

Bram Kerkhof
In reply to this post by Peter Lauer
Hi Peter,

There are a couple of assumptions here that are not always valid in
real-life situations. First and foremost, you should consider that
functionally there might not be a difference between losing a single part of
a complex system, or the whole system at once. Any single point of failure
(SPOF) can take the whole system out, and the added complexity of a full
star topology with a store-and-forward gateway keeping it all together will
only add more SPOFs into the design. This will definitely make it more
expensive, but not necessarily more reliable.

As John pointed out, redundancy should be an integral part of the design,
and increasing complexity has the tendency of decreasing the reliability
because every added component has an impact on the system as whole. On top
of that (and there are quite a few designers that forget this step): a
system should be able to detect when it is running in degraded mode (i.e.:
one layer of redundancy has failed) so that it can be fixed as soon as
possible.

CAN, being developed for a very aggressive environment (automotive), has
been designed from the ground up to offer a maximum of reliability with a
minimum of complexity, and the fact that it has become as pervasive as it is
right now is a testament that those design goals have been met.

That being said: any node can fail, any wire or connector can
break/short/corrode. Using CAN for communication does not resolve that, but
neither does any other single communication network. Within the context of
automotive, there are two common approaches to factor in reliability:
- physical layer redundancy (i.e.: use fault-tolerant transceivers that can
survive single conductor open/short scenario)
- network topology with built-in redundancy

Physical layer redundancy is more finicky in design and implementation
because the network (w.r.t. impedance) has to be designed as a whole,
maximum speed is lower and it cannot offer fault tolerance for all
scenarios. On the plus side it will provide an added level of reliability
over a single pair of wires for a limited cost. Consequently, it is used for
non-critical applications (vehicle comfort features such as AC, window
control, seat settings, ...).

Once nodes are deemed to be critical for the safe operation of the vehicle,
one single connection does not cut it. In most cases, a vehicle has multiple
CAN (or other, like J1708 or Flexray) networks that are interconnected at
gateway nodes. On top of that, critical nodes (ECU, ABS/ESP, transmission)
will have individual connections to multiple networks, so that more than one
network has to fail before communication between the critical nodes is out.
(Failsafe design of the nodes does not stop after that; every node should
have a failsafe envelope in which to operate when communication is
completely out).

Going back to the system you described, it makes a lot more sense to design
a proper network topology with built-in redundancy (but still based on a bus
topology instead of point-to-point so you don't lose the advantage of
simplicity in the design). This could be as simple as figuring out which
nodes are critical to the operation of the machine, and connecting them
additionally to a separate bus -- preferably using wires routed on a
different path from the other network. This kind of design will offer
redundancy for the critical components and allows for proper detection of
degraded modes (critical nodes can compare data on both networks for
differences). On top of that it will be cheaper, simpler and offer far more
reliability than a switch to a star-based topology.

Reliability and redundancy (and consequently: security) are integral parts
of the system design. Stating that using a bus topology is less reliable
than a star topology is (in my personal opinion) a bit disingenuous if you
don't take the overall system design goals (and the execution) into account.

cheers,
Bram
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Peter Lauer
Sent: zaterdag 4 juni 2016 17:05
To: [hidden email]
Subject: [CANLIST] reliable CAN connection

Hi,
we recently reviewed a study that showed that the reliability of a system
goes down when you use one CAN bus instead of discrete connections. lets say
you have 3 actuators and 3 sensors on one bus, the bus goes down, you loose
all actuators and all sensors.

instead of going back to all discrete wiring, what about staying with CAN on
the actuator and sensor side but have a separate CAN channel on the
controller? Basically like the switch from BNC Ethernet to 10BaseT. Than
only one channel can go down at a time, and you still have control over the
rest.

Peter--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to
<[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: reliable CAN connection

heikki saha
Hello,

Let's take a little bit more accurate approach:

There are numerous fault modes in the cabling and same fault modes apply
for both CAN and discrete. Functional safety standards, such as ISO 13849,
define preferred fault modes to be covered and typical modes are wire
breaks and shortcuts to other wires, one by one. However, from the practice
we know that the "most exciting" failures are the ones between break and
short circuits -- resistance or conductance.

First, we need to gather information, how probable the failures are and
what are their consequences and in which probability it is possible to
detect the failures and perform fault reactions. In that sense, we result
6-0 for networks, because analog discrete communication has so low diagnostics
coverage, due to the fact that there does not exist packet format for
distinguishing between normal signal value and failure. So, if dependability
is an issue, don't even think about using any discrete communication.

Second, if you cannot implement cabling so, that MTTFd is low enough with
single channel, then you have to implement redundant communication. Again it
depends on your requirements, which is preferred approach. We have analyzed
that it is possible to reach SIL3 with 2-way redundant CANopen instrumentation,
where both heartbeat and RPDO timeout monitoring is used together with managed
network startup with consistency checks.

Third, even dependability may not be enough. There may also exist requirements,
according which your system shall tolerate 1 or more simultaneous errors. Such
availability requirements are typically leading into higher redundancy.

Fourth, practice has shown that most common failures are coming from humidity
getting into connectors and various human mistakes in component logistics and
assembly. So, importance of standardized design and manufacturing process
defined e.g. by CANopen should not be underestimated. It is clearly stated in
the safety standards, that analyses shall cover all known threats over the
entire life cycle of the system under development. Those threats, which do not
apply, shall be defined based on the analysis.

Just as an example of diagnostics coverage: Categorical and spatial accuracy of
error detection is more accurate in single channel CANopen than 3-way redundant
analog sensor connection. All the differences come from extremely unreliable
analog signalling, which quite often either causes extra failure indications
and sometimes failures have been hidden the failure indications sent by the
sensors. Even with single CANopen network you can quite efficiently distinguish
between sensor and interconnection failures, and perform full consistency check,
thanks to the device type and identity objects in each device.

If all of the sensor/actuator pairs exist for different function, there is no
redundancy and just using single CANopen channel is far more reliable than any
comparable analog instrumentation. If they are redundant, based on typical MTTFd
values of sensors and actuators, 2-way redundant communication is enough, if
there do not exist special threats from the operating environment.

Best regards,

-H

Heikki Saha, CTO
  M.Sc. Automation
  Dr.Tech. Electronics
TK Engineering Oy
Mail address:  P.O. box 810, FIN-65101 VAASA
Visit address: Yrittäjänkatu 17, FIN-65380 VAASA
+358 (0)50 588 6894
[hidden email]
http://www.tke.fi/
http://www.canopen.fi/

----- Original Message -----
From: "Bram Kerkhof" <[hidden email]>
To: [hidden email]
Sent: Sunday, June 5, 2016 4:27:27 PM
Subject: RE: [CANLIST] reliable CAN connection

Hi Peter,

There are a couple of assumptions here that are not always valid in
real-life situations. First and foremost, you should consider that
functionally there might not be a difference between losing a single part of
a complex system, or the whole system at once. Any single point of failure
(SPOF) can take the whole system out, and the added complexity of a full
star topology with a store-and-forward gateway keeping it all together will
only add more SPOFs into the design. This will definitely make it more
expensive, but not necessarily more reliable.

As John pointed out, redundancy should be an integral part of the design,
and increasing complexity has the tendency of decreasing the reliability
because every added component has an impact on the system as whole. On top
of that (and there are quite a few designers that forget this step): a
system should be able to detect when it is running in degraded mode (i.e.:
one layer of redundancy has failed) so that it can be fixed as soon as
possible.

CAN, being developed for a very aggressive environment (automotive), has
been designed from the ground up to offer a maximum of reliability with a
minimum of complexity, and the fact that it has become as pervasive as it is
right now is a testament that those design goals have been met.

That being said: any node can fail, any wire or connector can
break/short/corrode. Using CAN for communication does not resolve that, but
neither does any other single communication network. Within the context of
automotive, there are two common approaches to factor in reliability:
- physical layer redundancy (i.e.: use fault-tolerant transceivers that can
survive single conductor open/short scenario)
- network topology with built-in redundancy

Physical layer redundancy is more finicky in design and implementation
because the network (w.r.t. impedance) has to be designed as a whole,
maximum speed is lower and it cannot offer fault tolerance for all
scenarios. On the plus side it will provide an added level of reliability
over a single pair of wires for a limited cost. Consequently, it is used for
non-critical applications (vehicle comfort features such as AC, window
control, seat settings, ...).

Once nodes are deemed to be critical for the safe operation of the vehicle,
one single connection does not cut it. In most cases, a vehicle has multiple
CAN (or other, like J1708 or Flexray) networks that are interconnected at
gateway nodes. On top of that, critical nodes (ECU, ABS/ESP, transmission)
will have individual connections to multiple networks, so that more than one
network has to fail before communication between the critical nodes is out.
(Failsafe design of the nodes does not stop after that; every node should
have a failsafe envelope in which to operate when communication is
completely out).

Going back to the system you described, it makes a lot more sense to design
a proper network topology with built-in redundancy (but still based on a bus
topology instead of point-to-point so you don't lose the advantage of
simplicity in the design). This could be as simple as figuring out which
nodes are critical to the operation of the machine, and connecting them
additionally to a separate bus -- preferably using wires routed on a
different path from the other network. This kind of design will offer
redundancy for the critical components and allows for proper detection of
degraded modes (critical nodes can compare data on both networks for
differences). On top of that it will be cheaper, simpler and offer far more
reliability than a switch to a star-based topology.

Reliability and redundancy (and consequently: security) are integral parts
of the system design. Stating that using a bus topology is less reliable
than a star topology is (in my personal opinion) a bit disingenuous if you
don't take the overall system design goals (and the execution) into account.

cheers,
Bram
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Peter Lauer
Sent: zaterdag 4 juni 2016 17:05
To: [hidden email]
Subject: [CANLIST] reliable CAN connection

Hi,
we recently reviewed a study that showed that the reliability of a system
goes down when you use one CAN bus instead of discrete connections. lets say
you have 3 actuators and 3 sensors on one bus, the bus goes down, you loose
all actuators and all sensors.

instead of going back to all discrete wiring, what about staying with CAN on
the actuator and sensor side but have a separate CAN channel on the
controller? Basically like the switch from BNC Ethernet to 10BaseT. Than
only one channel can go down at a time, and you still have control over the
rest.

Peter--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to
<[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>