I have interest in using xmos in marine vehicle control applications that will need design to SIL2 and SIl3 compliance. Do others have experience of similar type xmos apps?(eg automotive, TUV et al)
..I posted this as a discussion thread in the Xmos group LinkedIn forum and John Edwards suggested I raise an xmos support ticket or mailed him directly. This is excellent development support however I'd intended a wider sphere of discussion realting to design requirements, so John has suggested I bring it here too. :)
My question was intended at a wider scope because although SIL 2,3,4 are fundamentally based on statistical determinism of likely failure, these have become interpreted in various standardised ways in various fields of engineering and are not in any way consistent.
My experience with the original transputer showed me that parallel structures with well defined sync, hardware prioritisation and scheduling and with true parallelism using multiple chips, was not at all like conventional embedded software design; it is more akin to hardware design. Now we have xmos with multi-cores(tiles) in the same package.
So the questions become what is acceptable redundancy.. what is acceptable supervisory/arbitrational process in the case of multiple redundancy. If interprocess scheduling and coms are hardware based then multiple tiles in one package are equivalent to a very high reliability multichip design ..unless there is thermal meltdown or total supply failure(partitioned in suited ways).
It is not just another microcontroller, and I think this needs exposing.
Xmos in Sil2, Sil3 applications
-
Bob
- Member
- Posts: 11
- Joined: Thu Oct 28, 2010 3:51 pm
-
Allein
- Member
- Posts: 12
- Joined: Wed Apr 04, 2012 5:48 pm
Hi Bob,
Being active in industrial control systems design, I'm also very aware of, and agree with your points on the advantages XMOS could bring in terms of System Integrity.
Anyway, this is a vast and complex domain that would be worth to have XMOS bringing in their own figures, specially in terms of:
- hardware scheduling reliability
- hardware inter-core comm & synch reliability
- external XLink reliability
- I/O ports reliability against metastability
- SEU (Soft Error) FIT rate, more specifically of their SRAM
- XCore processor susceptibility over the long-term to external disturbances (power ripple & drift, clock jitter & drift, EM noise, climatic cycling, ...) - are these topics somewhat tested in XMOS labs or some standard figures available from their Foundry ?
The improved reliability potential of the (XC) CSP-based programming paradigm against more "traditional" multi-processing programming methodologies has been extensively worked out in the past, and there is some interesting litterature on this topic.
XMOS has here another real potential to valuate - I'd love to have them jumping into this (or another, more proprietary) thread.
br
Alain
Being active in industrial control systems design, I'm also very aware of, and agree with your points on the advantages XMOS could bring in terms of System Integrity.
Anyway, this is a vast and complex domain that would be worth to have XMOS bringing in their own figures, specially in terms of:
- hardware scheduling reliability
- hardware inter-core comm & synch reliability
- external XLink reliability
- I/O ports reliability against metastability
- SEU (Soft Error) FIT rate, more specifically of their SRAM
- XCore processor susceptibility over the long-term to external disturbances (power ripple & drift, clock jitter & drift, EM noise, climatic cycling, ...) - are these topics somewhat tested in XMOS labs or some standard figures available from their Foundry ?
The improved reliability potential of the (XC) CSP-based programming paradigm against more "traditional" multi-processing programming methodologies has been extensively worked out in the past, and there is some interesting litterature on this topic.
XMOS has here another real potential to valuate - I'd love to have them jumping into this (or another, more proprietary) thread.
br
Alain