Re: What is the current language profile for concurrent, multi-core, safety-critical, hard real-time systems?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-08-01 06:19, Dennis Lee Bieber wrote:
> On Tue, 1 Aug 2017 01:45:22 -0000 (UTC), Adam Jensen <hanzer@riseup.net>
> declaimed the following:
> 
> 
>> That's interesting, thanks. I've been looking at the ARM Cortex-R8[1]
>> which seems like it might address some of these issues in its hardware
>> architecture.
>>
>> [1]: https://developer.arm.com/products/processors/cortex-r/cortex-r8
>>
>> I suppose that mapping an Ada run-time system onto that specific hardware
>> might require a significant investment.
>>
> 
> 	I suspect /very/ significant. Can you lock tasks to specific
> processors? If not, you run into the uncertainty in timing when a task gets
> loaded into a different core. Even if you can, can you show that the
> processing on one core will not impact another. As I understand it,
> lock-step doesn't help for independent tasks -- it's a redundancy mode in
> which a difference between the cores signals an exception condition (in
> flight systems, this would be a periodic compare between two independent
> /boxes/ to confirm that both are producing the same results).
> 
>> But more simply, this web page <http://www.ada2012.org/> says: "Ravenscar
>> for multiprocessor systems adapts a safe and widely used tasking profile
>> to modern architectures". Doesn't that seem to suggest that there exists
>> an Ada-2012 Ravenscar profile for multi-core systems? Is that mostly hype
>> or hokum?
> 
> 	There may be a profile -- but (again, from my little exposure in FMS)
> will it pass certification? There isn't yet enough history for multi-core
> to pass flight certification (granted, part of that may be that no company
> wants to spend the money to prove to the FAA that multi-core can be safe --
> dual single-core boxes can be validated as there is no "hidden" interaction
> on memory access, WCET is a single core determination).
> 
> 	Even Ada tasking may not be trusted (I was maintaining a program that
> used a small RTOS to create the processes, rather than having Ada tasks
> doing the work).
> 
> 
> 	A bit of a chicken&egg situation: there may be processors designed for
> multi-core real-time, and there may be companies who'd like to use them...
> But developing and getting software certified for use (again, my exposure
> is flight management systems) would have to be done on company R&D funds --
> since client companies probably won't pay for an "experiment"; they likely
> want just an upgrade to an existing single core system, where reuse may
> reduce the cost of certification for flight.
> 
> 	Automotive may be less critical -- a timing discrepancy isn't going to
> result in a few hundred people falling from the sky, one should be able to
> limp-mode to the shoulder of the road. (OTOH: between ABS, traction
> control, stability control, etc. I expect the next generation of drivers
> will not be able to react properly should the assists fault even
> momentarily)

I am quite pessimistic regarding how automotive approaches functional 
safety. My impression is that certification processes there are designed 
to cover up lack of elementary software safety behind tool chains, code 
generators and administrative overhead. If anything to happen then not 
there. (:-()

P.S. And there is a hard push to add security on top or bottom of all 
mess...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de