[SystemSafety] Static Analysis
Peter Bishop
pgb at adelard.com
Thu Mar 6 11:33:10 CET 2014
Michael Jackson wrote:
> Alvery:
>
> Yes, indeed. And a large part of the difficulty lies in formalising
> the given properties and behaviours of the domain (which it possesses
> independently of the controller) and formalising the constraints
> which the controller will impose on those properties and behaviours
> and the resultant actual behaviours that will be exhibited in system
> operation.
>
> Some formal methods (for example, Event-B) do attempt formal
> verification of the whole system (controller plus domain). Event-B is
> concerned (so far as I know) with discrete systems only. Its approach
> to formalising the physical world is not beyond criticism; but it is
> strong on formal (often automated) proofs of invariant
> properties---safety properties in the sense of 'not liveness'. The
> resulting formal models are still, however, very far from any
> practical implementation language for controller programs.
And course any formal model of the physical world is always limited by
our understanding of the physical world.
Peter Bishop
>
> Best wishes,
>
> -- Michael
>
>
>
>
> At 14:08 03/03/2014, GRAZEBROOK, Alvery N wrote:
>> Absolutely, I agree. My point was that current practice in formal
>> methods doesn't cross this boundary. My understanding is that you
>> could define a formal methods process roughly as:
>> 1. Understand the safety implications of the system and define the
>> safety properties
>> 2. Prove that your controller behaviour is consistent with the safety
>> properties, for the domain where the controller can affect them.
>>
>> The "wider physical world" bit happens at step 1, and only the outcome
>> is expressed formally in the safety properties.
>>
>> This interpretation covers SPARK process, and a formal process using
>> SCADE. It could also be said to cover the application of proof
>> checkers to VHDL in chip-design, and formal microprocessor designs or
>> proof of properties of communication protocols. In these cases, rather
>> than define safety properties, they select a set of correctness
>> properties and prove those.
>>
>> I would be interested in any examples where the formal verification
>> did cross the "physical world" boundary.
>>
>> Cheers,
>> Alvery
>>
>> ** the opinions expressed here are my own, not necessarily those of my
>> employer
>>
>> -----Original Message-----
>> From: Michael Jackson [mailto:jacksonma at acm.org]
>>
>> Yes. Surely "taking the discussion on to the system behaviour applied
>> to the wider physical world" beyond "the control / measurement
>> systems" is what it's all about, isn't it? It's only in the wider
>> physical world that the system purpose has meaning and the real costs
>> of safety failures are felt.
>>
>>
>> This email (including any attachments) may contain confidential and/or
>> privileged information or information otherwise protected from
>> disclosure. If you are not the intended recipient please notify the
>> sender immediately and delete this email and any attachments from your
>> system. Do not copy this email or any attachments and do not use it
>> for any purpose or disclose its content to any person. Airbus
>> Operations Limited disclaims all liability if this email transmission
>> has been corrupted by virus, altered or falsified.
>>
>> Airbus Operations Limited, a company registered in England and Wales,
>> with registration number 3468788. Registered office: Pegasus House,
>> Aerospace Avenue, Filton, Bristol, BS99 7AR, UK.
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
--
Peter Bishop
Chief Scientist
Adelard LLP
Exmouth House, 3-11 Pine Street, London,EC1R 0JH
http://www.adelard.com
Recep: +44-(0)20-7832 5850
Direct: +44-(0)20-7832 5855
More information about the systemsafety
mailing list