Skip navigation

Monthly Archives: January 2005

Man urinates his way out of avalanche | The Register

Just spotted Ollie at the start of a driving lesson, zooming away from Palatine.

Here I attempt to list (may be randomly at first) all of the keywords that I have come across whilst reading papers on the topic of dependability. I will add definitions to the keywords as time allows and I have developed an understanding of each keyword.

Attributes of Dependability

  • Availability
  • Reliability
  • Safety
  • Confidentiality
  • Integrity
  • Maintainability
  • The above attributes lead to security.

    Impairments of Dependability

  • Failures
  • Errors
  • Faults
  • Means of Dependability

  • Fault Prevention
  • Fault Tolerance
  • Fault Removal
  • Fault Forecasting
  • … here is McAnnette

    Ok, so Simon, my housemate, is currently going through some emotional turmoil and one way in which he his coping is by stuffing his face.

    He failed to finish the super-mega-sized bap though this could be blamed on watching Tribe, a BBC2 documentary, when the presenter began to vomit profusely after taking a hallucinogen that sends him into a three day trip.

    This week a crowd of us helped Lydia celebrate her 22nd birthday by visiting the usual bars with a rather early departure from the southside to the ghetto, straight into Walkabout. No live band, but a DJ who is guaranteed to play the identical cheesy tracks that the band would have passionately yet nauseatingly played anyway. Here’s Lydia styling one her many bags that doubles up as a handy photo prop.

    So what else? Started a new module, did the nodding of the head routine whereby your head slowly drops, eye-lids close and suddenly five seconds later you re-awake with a violent jerk, and you feel as if everybody, including the lecturer, is looking in your direction. I left halfway through for sleep as it would have only became more embarrassing and besides, my brain was not receiving input, it wanted to close down, hit the rhythms of Circadia.

    Last night a few friends and I went to a Ceilidh, a Scottish dancing evening held by Ustinov college (the postgraduate college here in Durham). I managed one dance, if you can call it that, which consisted of turn-based repeated sequence of dance moves that went on for what seemed a bloomin’ long time.

    Oh and I’ve just tried writing my CV on the off-chance that I apply for employment somewhere sometime soon. It’s naff so this week I’m attending a session provided by the Durham careers service on how to write the perfect CV. I am torn between getting a real job or having a go at business venture with some friends. I definitely do not want a real job, they scare me, but I know it is the more sensible option. But what happens if I have a go at running a business for a year and it goes nowhere? No one will want to employ me after that, I haven’t had a job in years, I need some real experience. Or does having a go at business constitute worthwhile experience? If anybody knows then please give me guidance.

    The Hazard and Operability (HAZOP) review is a systematic way to identify hazards to staff, facilities, and the environment. This method was first developed in Great Britain at ICI in 1964 and has been refined several times since.

    The HAZOP technique involves the use of “Guide Words” to stimulate an imaginative yet systematic search by the investigative team for possible hazards and operational difficulties. This is typically done in a series of “Examination Sessions” where P&IDs, Sequence of Operations and other detailed process specification documents are reviewed for hazards by asking questions such as what would happen in the event of “higher than expected flow”, “lower than expected flow”, “no flow”, or “reverse flow”.

    HAZOP techniques were developed for the chemical and processing industry but now the technique extends to identifying safety-critical risks in the software engineering process. One method in identifying the safety requirements that need to be incorporated into software is the HAZOP analysis. These safety requirements add constraints to the software design in methods such as prevention (not allowing the system to enter hazardous states), detection (spot when the system has entered dangerous state(s)) and correction (move the system from a dangerous state).

    Other hazard analysis techniques include Fault-Tree Analysis, FME (Failure Mode and Effects) Analysis and HAZID analysis. See R2A site for a comprehensive survey of hazard techniques.

    Nine a.m. we had our first Software Dependancy lecture. The lecturer seems to know his stuff being part of DIRC – Interdisciplinary Research Collaboration in Dependability of Computer-Based Systems.

    There are four core topics that the umbrella term of ‘dependality’ cover. These are:

    • Availability
    • Reliability
    • Safety
    • Security

    Security underpin each of the topics because security breaches, in whatever form, will affect availability, reliability and safety. Less significant, or less researched topics that form part of the dependability definition are risk, structure (e.g. using appropriate coding structures to produce predictively more dependable systems), diversity (use voting system to come to decision), timeliness (predict failures) and responsibility (is the programmer, installer, user responsible?). These five topics are all affected by a human element or input. A number of other topics that apply to dependability are repairability, maintainability, survivability and error tolerance.

    This is just a quick intro of what dependability covers though I’m sure I’ve missed out topics which will hopefully follow in further blogs.