Re: reliable CAN connection

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
[email protected]
http://www.tke.fi/
http://www.canopen.fi/

----- Original Message -----
From: "Bram Kerkhof" <[email protected]>
To: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf
Of Peter Lauer
Sent: zaterdag 4 juni 2016 17:05
To: [email protected]
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
<[email protected]>

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