Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Metamodel'

Entries that have been tagged with 'Metamodel'.-

Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event?

by Nic Plum on Thursday 07 January, 2016 - 19:37 GMT

Posted in Architecture FrameworkTRAK

Tags: definitionhazardmetamodelontologyriskstandardthreattrakviewpointvulnerability

Changes have been made to TRAK to support the description of risk and event sequences in the guise of the SVp-11 Solution Event Causes and SVp-13 Solution Risk Viewpoints. This has been a piece of work underway for at least 3 years but it seemed necessary to publish it so that the viewpoints and tuples can be exposed to wider testing i.e. used in anger.

As with most of this sort of work there is a limit to the amount of theorising that is possible and it’s necessary to test the pragmatism and utility. It’s likely therefore to undergo some tweaking. If any relationship or metamodel entity is not needed then it should be removed since the overall aim is to work with the minimum metamodel needed to just be adequate. A larger metamodel is not only harder to maintain and keep consistent but because it is only there to support the concerns in the set of TRAK viewpoints (specifications for views cf ISO/IEC/IEEE 42010:2011) it follows that a larger metamodel makes definition of a consistent set of viewpoints harder. With more entities and relationships it is also likely that an architecture description can become more complex and require more effort to present it clearly to get the meaning across (at least to a Mk 1 Human Being since being based on triples a TRAK architecture description is machine-readable and analysable). Every tuple in the TRAK metamodel has therefore to earn its keep / justify not being removed.

Solution Risk

In a previous posting I identified why we think, in TRAK at least, that a risk is a type of event and why many of the current definitions of risk do not actually define what a risk is (only how you might calculate a number or metric i.e. probability of occurrence x impact severity).

We’ve tied risk to the solution because we think that this is where it most often manifests itself in terms of design features or changes to the design of the system of interest to mitigate it. In engineering terms it is really the cumulative risk exposure to people that drives design change hence it makes sense to be able to relate risk, vulnerability, threats and mitigation to a solution design whether the causing agent or the impacted one.

TRAK therefore supports the following triples / tuples for describing risk:-

http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons” href=“https://commons.wikimedia.org/wiki/File%3ATRAK_metamodel_part_2_safety_security.jpg”>TRAK metamodel part 2 safety security

  • Resource (System, Software, Physical, Role, Job or Organisation) has Vulnerability
  • Function has Vulnerability - what the Resource does
  • Resource Interaction has Vulnerability - the exchange between Resources
  • Interaction Element has Vulnerability - what is exchanged between Resources
  • Resource poses Threat (synonym Hazard)
  • Threat exploits Vulnerability
  • Threat to Resource
  • Threat to Function
  • Threat to Resource Interaction
  • Threat to Interaction Element
  • Threat poses Risk
  • Resource exposed to Risk
  • Risk is managed by Mitigation
  • Mitigation uses Function
  • Mitigation uses Resource

By way of a small example using a small subset of the above we have a nuclear reactor.

SV-13 Solution Risk View (fragment) - Nuclear Reactor

It is possible to identify an external actor as the origin of the threat (hazard) - ‘Resource 1 poses Threat to Resource 2’. Similarly mitigation might be a result of a part of the same resource or it might require a different one (‘Resource 1 is exposed to Risk is managed by Mitigation uses Resource 2’).

In all of this the description of Risk, Vulnerability, Threat (Hazard) and Mitigation can be linked to the description of the solution or part of the solution. This therefore enables the solution design to be modified in response or the mitigation to be altered in response to a design change so the cause and effect is always visible in the architecture description.

So far all of this is pretty straightforwards. The “toughie” is:-

  • Risk is a Event

This is tricky not because there is any doubt that a Risk is a type of Event. A risk typically is associated with a probability of occurrence and an impact severity. If we are thinking about an event in the way it would be used in, say, Fault Tree Analysis (FTA) then it also has a probability of occurrence. It too can have an impact severity. So are there differentiating attributes of a risk (event)? We couldn’t think of any - suggestions welcome. The rationale for having a separate Risk metamodel element was simply that people might expect to see elements labelled as ‘Risk’ because they might not equate ‘Event’ with the description of a risk (affordance and visibility).

Note. Although there isn’t a difference in the attributes there is a distinction in the possible values A Risk and an Event can take. A Risk, by definition is always uncertain but possible therefore 0 < probability of occurrenceRisk < 100% whereas a ‘straight‘ Event may be impossible or certain and therefore 0 ≤ probability of occurrenceEvent ≤ 100%. Risk therefore seems to occupy a subset of the range of values for Event.

Is this worth having 2 distinct elements, particularly since the inheritance (‘is a’) means that we also have:-

  • Risk caused by Risk
  • Risk impacts on Resource
  • Risk caused by Resource
  • Risk AND / OR / etc. Risk

and this is less clear when Risk and Event are separate entities on the metamodel diagram.

If there was the one element, Event, then it would still allow risks (Events) to be clustered or grouped which would allow the SVp-11 to be used to describe and identify common causal risk (events) and therefore suggest ways in which risks might be managed. The only penalty seems therefore to be 1) visibility - can risks be identified as such when typed as Event? 2) affordance - is it obvious that an Event element can be used to describe a risk?

Can anyone justify why Risk and Event should be distinct or why they should be subsumed into Event? Clearly from a TRAK-management point of view it would be better to apply the Highlander Principle (“there shall only be one”) but this might overridden by the UI / HCI aspects.

Thoughts?

Comments

Comment on this article

Related Articles

    Sharing tags:

    External Links

    NATO Architecture Framework Metamodel v3.1 Surfaces

    by Nic Plum on Monday 09 August, 2010 - 15:37 GMT

    Posted in Architecture FrameworkNAFNews

    Tags: c3metamodelnafnatonewsreleaseresourcespecification

    NATO logoA definition/description of the NATO Architecture Framework Metamodel version 3.1 is now publicly available (the definition of the framework had previously disappeared from public view).

    Currently only the document that specifies the metamodel is available - this is one part of the overall definition of the NATO Architecture Framework. The documentation that specifies the architecture views for version 3.1 isn’t yet available. The document that is available is Chapter 5 - NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) .

    Without a complete document set and without a change record yet it’s hard to make an assessment, but ...

    • NAF 3.1 now seems to be much closer to the MODAF 1.2.003 metamodel (MODAF is now at 1.2.004)
    • The number of subviews has increased in total from 47 at 3.0 to 49 at 3.1 - with notable changes in the NATO Service-Oriented Views (NSOVs) which now align with MODAF
    • the usage context of Resources (Capability Configuration, Artefact, Role, Post, Organisation, Software) can now be specified - this is a way of allowing exchange of models which were previously unexchangeable owing to the choices allowed by the NAF metamodel in typing a real world thing e.g. system vs platform vs artefact with the result that different architects would choose different stereotypes. The conflict in choice is still present but the usage context allows the architect to say, for example, this Platform is being used as a System. This is identical to MODAF from 1.2.003.
    • any Resource is allowed to have a function now (NAF previously divided Resources up into ‘functional’ and ‘non-functional’
    • any Resource can now interact with another Resource

    Some niggles still remain e.g. the ‘system’ stereotype is really not a first class player and cannot itself contribute to capability or have parts which are other resource-like things - so no complex system or including the man with the machine as part of the system. This looks as though it has to be achieved using a Capability Configuration as a system and ignoring the fact that the System stereotype cannot represent a system. The new definition of System in v 3.1 doesn’t help - ‘The usage of an artefact as a System in a CapabilityConfiguration’ - as it doesn’t actually define what a system is.

    Still the increased flexibility wrt Resources is a significant step forwards in representing the real world.

    Update 11th November 2010
    The definition for the NATO architecture framework seems to have disappeared again.

     

    Comments

    Comment on this article

    Related Articles

      Sharing tags:

      External Links

      TRAK is in the Wild - Now an Open Source Enterprise Architecture Framework

      by Nic Plum on Sunday 21 February, 2010 - 10:02 GMT

      Posted in Architecture FrameworkTRAKNewsStandards

      Tags: definitiondepartment for transportenterprise architectgfdlgnulondon undergroundmdgmetamodelopen sourceprofilereleasesourceforgesparx systemstrakumlviewpoint

      GNU Logo

      TRAK has been released, thanks to the foresight of London Underground Ltd., under an open source license.

      Releasing TRAK under open source is important because

      • it is a standard to facilitate the exchange of architecture models
      • it recognises that there are many who could contribute expertise if allowed to do so - any with the need or energy/motivation can participate
      • it provides a feasible maintenance and support system - one where TRAK has the wherewithall to heal itself
      • it keeps the cost of using the standard to a minimum - since architecture is a form of communication we shouldn’t tax it!
      • it represents pragmatism in terms of releasing early, not waiting for perfection and in collaborating for the common good

      The UK Department for Transport are the sponsor of TRAK as part of a wider systems engineering initiative.

      The release of TRAK has been split into 4 products.

      The first 2 parts form the logical definition of TRAK.

      • the TRAK metamodel. This specifies the allowable object types and relationships that can be used. In essence it provides the language that an architect can use through the set of nouns and verbs. It includes a simplified metamodel for easy reference. It also includes a detailed comparison against MODAF 1.2 in order to set an initial baseline. One of the reasons for release using the GNU Free Documentation License (GFDL) is that the History section is preserved together with attribution to those who help develop TRAK. The metamodel is at trakmetamodel.sourceforge.net
      • the TRAK architecture viewpoint definitions. TRAK adopts ISO 42010 / IEEE 1471 practice by having a viewpoint for each architectural view that specifies the concerns addressed, the allowable objects (from the metamodel), the suggested presentation format and the consistency rules. It includes a comparison against MODAF 1.2 view set. It is released as open source under the GFDL at trakviewpoints.sourceforge.net

      The second 2 parts are implementations against the logical definition.

      • the MDG Technology for TRAK. This is a Sparx Systems Enterprise Architect (EA) file that contains the architectural model used to create both the MDG plugin that implements TRAK in Enterprise Architect and the UML profile for TRAK which is used by Enterprise Architect and any other UML modelling tool. It represents the implementation of both the TRAK metamodel and the TRAK viewpoint definition as far as is possible. It contains the EA plugin and the source EA project file. It is released under the GNU Public License version3 (GPL v3) at mdgfortrak.sourceforge.net
      • the UML profile for TRAK. This provides the set of objects and relationships defined within the TRAK Metamodel in a way that any decent UML modelling tool can use. It is released under the GPL v3 at trakumlprofile.sourceforge.net

      Not saying it’s perfect - we know it isn’t. It’s good enough for practical purposes and we have a list of things that need looking at. What I hope is, being open source, that anyone needing to apply it in a particular situation and finding it lacking can then get involved to solve the problem. Application and usability are all important - more so than any theoretical underpinning. The framework is not a system - this only arises when you add tools, people, organisations and therefore you always have to address visibility, navigation, affordance etc - in short the user interface for the whole thing. We hope in this way that TRAK will be user-centric and problem-led rather than specification-centric.

      If you do want to get involved there are forums set up at the TRAK Viewpoints and TRAK Metamodel sites.

       

      Comments

      Comment on this article

      Related Articles

          Sharing tags:

          External Links

          1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
           

          All articles/posts © of the respective authors

          Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.