${taskforce.name} Avatar
  1. OMG Task Force

Dependability Assurance Framework for Safety-Sensitive Consumer Devices (DAF) 1.0 FTF — All Issues

  • Key: DAF
  • Issues Count: 38
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DAF-50 Confusing arrow in the Figure 9-2 (DPM) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-21 XMI issue -- C (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-20 Association Issue -- B (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-19 English language correction -- A (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-22 BPMN issue -- D (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-35 Software Calibration V&V issue -- Q (On behalf of M.Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-34 Simplification Process issue -- P (On behalf of M.Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-31 Terminology issue -- M (On behalf of M.Haus) DAF 1.0b1 DAF 1.0 Closed; No Change closed
DAF-16 section 8.3 (Dependability Allocation Argument) needs rephrasing DAF 1.0b1 DAF 1.0 Resolved closed
DAF-18 Assorted english language corrections DAF 1.0b1 DAF 1.0 Resolved closed
DAF-17 Is section 9.1 normative or informative? DAF 1.0b1 DAF 1.0 Resolved closed
DAF-14 Label Section 8.1 as non-normative DAF 1.0b1 DAF 1.0 Resolved closed
DAF-6 Replace SACM XMI with the new version DAF 1.0b1 DAF 1.0 Resolved closed
DAF-26 English language correction -- H (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-25 Rationale issue -- G (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-30 System Engineering process issue -- L (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-29 Error Model issue -- K (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-33 Code Generation process issue -- O (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-32 Software development Process -- N (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Resolved closed
DAF-9 Change all diagrams from bitmaps to vector graphics DAF 1.0b1 DAF 1.0 Resolved closed
DAF-12 Sentence doesn't parse DAF 1.0b1 DAF 1.0 Resolved closed
DAF-13 Label figure 7-8 as non-normative DAF 1.0b1 DAF 1.0 Resolved closed
DAF-5 Section 9.2 P46 Figure 9-2, DAF 1.0b1 DAF 1.0 Resolved closed
DAF-4 Section 7.1.1 P7 DAF 1.0b1 DAF 1.0 Resolved closed
DAF-3 Section 7.1 P6 Figure 7-3 DAF 1.0b1 DAF 1.0 Resolved closed
DAF-2 Issue Sample DAF 1.0b1 DAF 1.0 Closed; Out Of Scope closed
DAF-8 DCM import SPEM2 DAF 1.0b1 DAF 1.0 Resolved closed
DAF-7 BPMN XMI of DPM modifies character code. DAF 1.0b1 DAF 1.0 Resolved closed
DAF-24 UML reference # issue -- F (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Closed; No Change closed
DAF-23 Reference issue -- E (On behalf of M.Haus) DAF 1.0b1 DAF 1.0 Closed; No Change closed
DAF-28 Attribute issue -- J (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Closed; No Change closed
DAF-27 Dependency issue -- I (On behalf of M. Haus) DAF 1.0b1 DAF 1.0 Closed; No Change closed
DAF-11 Section 6 needs re-labelling, rearranging DAF 1.0b1 DAF 1.0 Resolved closed
DAF-10 Reword "Suggested conformance points" DAF 1.0b1 DAF 1.0 Resolved closed
DAF-15 Make example time-independent DAF 1.0b1 DAF 1.0 Resolved closed
DAF-76 SACM1.1 compliance DAF 1.0b1 open
DAF-51 Dependability Process Model (9.2) is poor DAF 1.0b1 open
DAF-52 "Dependabilty Analysis" describes only Threat Analysis, DAF 1.0b1 open

Issues Descriptions

Confusing arrow in the Figure 9-2 (DPM)

  • Key: DAF-50
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    In the figure 9-2 (DPM), there is a confusing arrow from "Dependability Argument Construction" to "Dependability Requirements Definition" specified. The arrow should be from "Dependability Argument Construction" to the diamond (judgement block" in the top left corner of the figure so that the arrow can be connected to "Dependability Analysis".

  • Reported: DAF 1.0b1 — Tue, 12 May 2015 06:29 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The arrow is to be removed

    The arrow is going to be removed because the arrow is misleading as if the "Dependability Requirements Definition" process requires an input from the "Dependability Argumentation Construction" process which is a downstream process of the "Dependability Requirements Definition".

  • Updated: Tue, 22 Dec 2015 15:04 GMT

XMI issue -- C (On behalf of M. Haus)

  • Key: DAF-21
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    There are some misspelled words in the generated XMI, which concerns me. This would imply that the XMI is not automatically generated from the model, which will cause maintenance problems. For example:
    Figure 8 9 - Modification Argument Part of the DAC template for Evolutionary Development Argument Structure "ModificationArgument" was misspelled.
    The XMI should be generated from the model to ensure a correct and consistent specification.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:37 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Fix the misspell

    The misspells are to be fixed as follows and the xmi file with correction is attached below together with the old xmi file for comparison.

    ・Static Dependability Analysis Argument

    sufficently
    ->
    sufficiently

    ・ProvenInUseArgument

    condintion
    ->
    condition

    ・Modification Argument

    condintion
    ->
    condition

    ・DependabilityAllocationArgument

    arctecture
    ->
    architecture

    adeaute
    ->
    adequate

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Association Issue -- B (On behalf of M. Haus)

  • Key: DAF-20
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    On the vast majority of the diagrams, the associations are not named. This is not normally a problem but is in this specification. This is because the associations are referenced in the text. For example:

    Figure 7 13 - Assessment package
    Associations
    conform:Confirmation Review [1]
    checks whether Artifact satisfies the Assurance Requirement.
    refer:Confirmation Review [1]
    specifies the reference of Assurance Requirement by Confirmation Review.

    Since the associations are listed without names on the diagrams, it is difficult to determine which are which.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:34 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The association names are to be added

    The original issue raised by Mathew under "for example..." has been already fixed in the beta 1 and no longer a problem.

    The association names are added in the figure 7-13 which is attached in the DAF-9.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

English language correction -- A (On behalf of M. Haus)

  • Key: DAF-19
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    The term "exceptional treatment" is used several times in the specification. I am not sure what it means. Possibly you mean "optional step" or "additional activity" or some other combination of words.
    .

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:33 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to remove the phrase

    The following sentense is going to be removed from the specification as the sentence is over specified and exaggerated. Likewise, all the sentences with "exceptional treatment" (4 places) are going to be removed for the same reason.

    9.3.2 : When the existing System Requirements Definition has been found as insufficient in the course of the System Architecture Design, it is possible to rework the System Requirements Definition as an exceptional treatment.

    9.3.3 : When the existing System Architecture Design has been found as insufficient in the course of Hardware Development, it is possible to rework the System Architecture Design as an exceptional treatment.

    9.3.5 : When the Hardware Development results and/or the Software Development results have been found as insufficient in the course of Verification and Validation, it is possible to rework the Hardware Development and/or the Software Development as an exceptional treatment. Major rework may be treated as an issue that should be treated in the next development loop.

    9.4.2 : When the Difference Analysis result has been found as insufficient in the course of the Impact Analysis, it is possible to rework the Difference Analysis as an exceptional treatment.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

BPMN issue -- D (On behalf of M. Haus)

  • Key: DAF-22
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    The BPMN diagrams do not show the inputs and outputs for the activities in section 9. For example, the diagram in section 9.2.1 lists all inputs and outputs as artifacts even though there are several.
    "The inputs of this activity are

    • Product Plan provided by upper level processes including Planning,
    • Incident Reports from the Problem flow, and
    • Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity."
      Is there any way to show these (and all other) inputs and outputs on the process diagrams? It would help make them standalone. Artifacts seems to be very little to go on.
  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:38 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Inputs

    Those inputs specified in the spec are just examples and we do not think they should be included in the BPMN diagrams. We will explain those are examples in the main text instead as follows. Likewise, all the descriptions related to inputs and outputs are going to be modified accordingly.

    OLD :
    The inputs of this activity are

    • Product Plan provided by upper level processes including Planning,
    • Incident Reports from the Problem flow, and
    • Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity.

    NEW :
    As examples of inputs, they are the following documents;

    • Product Plan provided by upper level processes including Planning,
    • Incident Reports from the Problem flow, and
    • Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity.
  • Updated: Tue, 22 Dec 2015 15:04 GMT

Software Calibration V&V issue -- Q (On behalf of M.Haus)

  • Key: DAF-35
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    9.3.4.7 Software Calibration & Verification & Validation
    "Various frameworks to standardize and generalize software and to use them in various products universally are developed in order to reduce control software development cost and to improve efficiency of the process. Calibration is a process to tune parameters implemented in software according to the specific product requirements and target market environment. It is based on the possibility of using the same software for various products with varying parameters."
    This is more an activity of developing software product lines rather than calibration V&V. It is normally done post-production over the course of several projects and not here as restructuring can change the size, performance, reliability, etc. It can also be done prior to starting the development to try to identify reusable features. At this stage, it is far too late.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 02:01 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Propose to remove sentences

    The following sentences are going to be removed as suggested, as the description contains some post-development activities.

    Sentences to be removed;
    "Various frameworks to standardize and generalize software and to use them in various products universally are developed in order to reduce control software development cost and to improve efficiency of the process. Calibration is a process to tune parameters implemented in software according to the specific product requirements and target market environment. It is based on the possibility of using the same software for various products with varying parameters."

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Simplification Process issue -- P (On behalf of M.Haus)

  • Key: DAF-34
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    9.3.4.5 Simplification Optimization
    "Therefore investigation to achieve equivalent quality control by simplified and/or optimized approach considering constraints of implementation size, cost and so on."
    Please rephrase for clarity.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 02:00 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to rephrase the sentence

    OLD : Therefore investigation to achieve equivalent quality control by simplified and/or optimized approach considering constraints of implementation size, cost and so on.

    New : Therefore, an implementation to achieve equivalent quality of the control model is deployed with simplified and/or optimized approach for codes, considering constraints of implementation size and cost.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Terminology issue -- M (On behalf of M.Haus)

  • Key: DAF-31
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    "In this clause we use the terminology of Control Software Development process instead of Control Software Development activity, and also use the terminology of activity instead of task and the terminology of task instead of sub-task, for simplicity."
    Why change the terminology? It would be better to use the same terminology throughout the document and consistent with BPMN, since that is what is being used.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:55 GMT
  • Disposition: Closed; No Change — DAF 1.0
  • Disposition Summary:

    Activity in SPEM is picked instead of Task in BPMN

    The following sentence is going to be added in the Section 7.3.2.

    In this document, the term Activity is used according to SPEM2.0, instead of the term Task to BPMN as the conceptioal model of process follows SPEM2.0.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

section 8.3 (Dependability Allocation Argument) needs rephrasing

  • Key: DAF-16
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In sysa/14-11-01, section 8.3 (Dependability Allocation Argument), the example is very dense and poorly-formatted. Please re-phrase & re-format to be clearer.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:40 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Section to be re-phrased

    All the sentences in 8-3 are to be shrunk for visibility.

    We will rewrite the sentences so that the sentences are definition of dependability allocation argument, and reduce the size of the sentences as possible

    Old
    Figure 8-1 depicts DAC templates for Dependability Allocation Argument. The DAC template for Dependability Allocation Argument represents that the allocation of dependability requirements of the target architecture is adequate. This template is recursively used for each sub-architecture. The term architecture is used for represents either “System of systems”, “System”, “Component”, or “Implementation” (see Architectural Concept in Clause 7.1). For example, if a system S consists of sub systems S1 and S2, and the threat and environmental list for S is derived as h1,…, hn, and the dependability requirement is D (derived from Dependability Requirements Analysis), then the top claim “C1: Dependability allocation of System S for each system/component/implementation is adequate” is decomposed into the following three sub claims: “C3: Dependability allocation of System S1 for each sub architecture is adequate”, “C4: Dependability allocation of System S2 for each sub architecture is adequate”, and “C2: Allocation of D1 to S1, Allocation of D2 to S2 are adequate.” In this argument, the dependability requirement D is divided into D1 and D2, and they are allocated to S1 and S2, respectively. C3 and C4 are then decomposed into sub claims using this DAC template, according to the structure of S1 and S2, respectively. The adequacy of the decomposition of D into D1 and D2 is assured in the argument of sub claim C2. Threat and environment list for S: T=h1,…,hn is divided into T1 and T2. This division is derived as the result of Dependability Analysis of DPM. Note that the sum of T1 and T2 is not necessarily equals to T: the sum may be less than T.
    The XMI file for the DAC template for Dependability Allocation Argument is DependabilityAllocationArgument.xmi (normative).

    New
    Change points: remove ":" in sentences and figure 8-1
    Change all figures into PDF.


    Figure 8-1 depicts DAC templates for Dependability Allocation Argument. The DAC template for Dependability Allocation Argument represents that the allocation of dependability requirements of the target architecture is adequate. This template is recursively used for each sub-architecture. The term architecture is used for represents either “System of systems”, “System”, “Component”, or “Implementation” (see Architectural Concept in Clause 7.1). System S consists of sub systems S1 and S2 (this template assume two sub systems, but the number can be modified according to the target system), and the threat and environmental list for S is derived as h1,…, hn, and the dependability requirement is D (derived from Dependability Requirements Analysis), then the top claim “C1 Dependability allocation of System S for each system/component/implementation is adequate” is decomposed into the following three sub claims: “C3 Dependability allocation of System S1 for each sub architecture is adequate”, “C4 Dependability allocation of System S2 for each sub architecture is adequate”, and “C2 Allocation of D1 to S1, Allocation of D2 to S2 are adequate.” In this argument, the dependability requirement D is divided into D1 and D2, and they are allocated to S1 and S2, respectively. C3 and C4 are then decomposed into sub claims using this DAC template, according to the structure of S1 and S2, respectively. The adequacy of the decomposition of D into D1 and D2 is assured in the argument of sub claim C2. Threat and environment list for S: T=h1,…,hn is divided into T1 and T2. This division is derived as the result of Dependability Analysis of DPM. Note that the sum of T1 and T2 is not necessarily equals to T: the sum may be less than T.
    The XMI file for the DAC template for Dependability Allocation Argument is DependabilityAllocationArgument.xmi (normative).

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Assorted english language corrections

  • Key: DAF-18
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Some english language corrections in sysa/14-11-01:

    1. Section 0.3 (PDF p12) "constitutes of five major elementary" -> "consists of five major elementary".

    2. Section 1 (PDF page 15) "methodology of the dependability argumentation" -> "methodology for the dependability argumentation". Also "integrating the conventional system assurance approach" -> "integrating conventional system assurance approaches". Also "as we are not experts of other systems" -> "as the authors are not experts in other systems".

    3. Section 2 (PDF page 15) "the clause" -> "clause" (2 places).

    4. Section 3 (PDF page 15) "following normative document contains" -> "following normative documents contain".

    5. PDF page 21 ""composed by" -> "composed of" (6 places)

    6. PDF page 24 "system of systems of system" -> "system or system of systems"

    7. References to "SPEM2" (10 places) should be references to "SPEM 2.0".

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:44 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The wording is to be fixed

    As for the comment 1, DAF 1.0b1 has no section 0, so it is no longer relevant.

    As for the comments 2 to 7, we would like to agree to revise them as you suggested.

    1. Section 0.3 (PDF p12) "constitutes of five major elementary" -> "consists of five major elementary".
    2. Section 1 (PDF page 15) "methodology of the dependability argumentation" -> "methodology for the dependability argumentation". Also "integrating the conventional system assurance approach" -> "integrating conventional system assurance approaches". Also "as we are not experts of other systems" -> "as the authors are not experts in other systems".
    3. Section 2 (PDF page 15) "the clause" -> "clause" (2 places).
    4. Section 3 (PDF page 15) "following normative document contains" -> "following normative documents contain".
    5. PDF page 21 ""composed by" -> "composed of" (6 places)
    6. PDF page 24 "system of systems of system" -> "system or system of systems"
    7. References to "SPEM2" (10 places) should be references to "SPEM 2.0".

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Is section 9.1 normative or informative?

  • Key: DAF-17
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In section 9.1 of sysa/14-11-01 (Iterative and Rapid Process) - is this section normative or informative? If the latter, please label it as such.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:43 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The section 9.1 is to be modified.

    The section 9.1 needs to stay normative to be modifed as follows;

    Original
    9.1 : Iterative and Rapid Process

    New
    9.1 : Overview of Iterative and Rapid Process

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Label Section 8.1 as non-normative

  • Key: DAF-14
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Section 8.1 (Introduction) should be labelled "Non-normative"

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:35 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Informative instead of non-normative

    OLD :
    Label Section 8.1 Introduction

    NEW :
    Label Section 8.1 Introduction (Informative)

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Replace SACM XMI with the new version

  • Key: DAF-6
  • Status: closed  
  • Source: University of Electro-Communications ( Dr. Yutaka Matsuno)
  • Summary:

    DAC SACM XMI files are not the newest ones. They should be updated

  • Reported: DAF 1.0b1 — Tue, 27 Jan 2015 01:46 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Keep to Use SACM 1.0

    SACM 1.1 is the latest SACM specification. However it does not include schema file for the sacm xmi, which makes hard to submit our DAC templates in compliance with SACM 1.1. Therefore we will propose to keep using SACM 1.0 as we originally did in Beta one. The attachment contains the original SACM 1.0 xmi just for reference.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

English language correction -- H (On behalf of M. Haus)

  • Key: DAF-26
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    Section 6.2
    "Now, given the fact that SSCD is a system to work for certain function, which aggregates systems to individually work for certain different function,"
    This phrase needs to be clarified. What does "work for a certain function mean"?

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:48 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to rephrase the sentence

    Original : Section 6.2
    "Now, given the fact that SSCD is a system to work for certain function, which aggregates systems to individually work for certain different function,"

    New : Section 6.2
    "Now, given the fact that SSCD is a system to implement certain function, which aggregates systems to individually implement certain different functions,"

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Rationale issue -- G (On behalf of M. Haus)

  • Key: DAF-25
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    6.1 Background and Rationale
    Would the existence of this specification made the analysis easier, solved the problem, or prevented the problem from occurring? It is a fair question given the use of the example as a rationale for the creation of the spec. Also, does this improve on ISO 26262, which is the automotive safety standard?

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:46 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    A Use Case is conducted

    An experiment of the DAF standard was conducted to prove the applicability for practical use, where the DAF was applied for the functional safety in automotive industry. A summary version of the use case is prepared as attached, which is going to be added in an annex.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

System Engineering process issue -- L (On behalf of M. Haus)

  • Key: DAF-30
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    9.3 Systems Engineering Process
    There are a lot more activities in the systems engineering process. Not all are always necessary. You should mention that this is the required subset.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:54 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to add sentences

    The following sentences are going to be added in the last part of Section 9.3

    NEW sentences:
    "There are a lot more activities in the systems engineering process, but not all are always necessary. These are the required subset."

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Error Model issue -- K (On behalf of M. Haus)

  • Key: DAF-29
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    Figure 7 12 - Error Model
    I would have thought that a threat was made up of zero or more failures, errors and faults, with at least one of them existing. The multiplicity shows just one of each.
    Also, Randam should be spelled random.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:52 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Model will be changed and typo be fixed.

    According to Laprie's definition, which we use as a reference, the threat is a generic term for fault, error and failure. So we would like to suggest to remove all shared aggregations and place the Threat as a super-class of fault, error and failure.

    We will revise the typo "Randam" as you suggested.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Code Generation process issue -- O (On behalf of M. Haus)

  • Key: DAF-33
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    9.3.4.6 Code Generation
    "The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. "
    Auto-coding can provide the correct code if the auto-generator is configured correctly. I have done so on several projects.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:58 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to add sentences

    OLD : 9.3.4.6 Code Generation
    "The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. "

    New : 9.3.4.6 Code Generation
    "The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which sometimes cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. The auto-coded code is going to be further manually optimized for size or further manually enhanced with additional failure mode implementation "

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Software development Process -- N (On behalf of M. Haus)

  • Key: DAF-32
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    Figure 9 4 - The Correct Control Software models Should this be called the software development process?

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:56 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The name of figure is to be fixed

    The process is going to be named as Software Development Process.

    OLD : Figure 9-4 The Correct Control Software models

    NEW : Figure 9-4 Software Development Process

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Change all diagrams from bitmaps to vector graphics

  • Key: DAF-9
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    All the diagrams in sysa/14-11-01 are bitmaps, and hence look fuzzy at high magnification. Please find a way to generate vector diagrams (such as SVG diagrams or vector PDF), to make sure that a final ("formal") OMG specification has a professional appearance.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:21 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    All of the figures should be converted to the vector format.

    All of the figures are converted from bitmap to SVG format.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Sentence doesn't parse

  • Key: DAF-12
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Section 7.1.3 (Component) contains this sentence, which I cannot parse: "It is not almost a single Hardware and/or Software item, but compose several items of Hardware and/or Software."

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:31 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The sentence is to be modfied.

    Could we change like this? The sentence is gong to be removed and the previous sentence is going to be modified as follows;

    OLD :
    It is not almost a single Hardware and/or Software item, but compose several items of Hardware and/or Software.

    NEW:
    It consists Implementations that are more than one Hardware and/or Software.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Label figure 7-8 as non-normative

  • Key: DAF-13
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Figure 7.8 ("Sample extension of Dependability Attribute") seems to be a non-normative example - please label it as such.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:33 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Suggestion taken.

    We would like to revise it to "Figure 7-8 Sample extension of Dependability Attribute (Informative)" as suggested.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Section 9.2 P46 Figure 9-2,

  • Key: DAF-5
  • Legacy Issue Number: 19707
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    There are some multiple incoming arrows to activities.
    Multiple incoming arrow means parallel merge.
    In this case, loop-back arrow and initial arrow
    are merged.
    This means initial arrow (flow) should wait results
    of subsequent arrow(flow).
    It is impossible to perform this diagram.

  • Reported: DAF 1.0b1 — Fri, 9 Jan 2015 05:00 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    *The multiple incoming arrows are going to be assigned appropriately. *

    All activities with more than one incoming arrow are replaced with loop structure or exclusive-or. Figure 9-3 and 9-4 also had the same problem so we fixed and attached. The diagrams attached have a defect, which does not show the loop marker in pdf format. It appears that the tool we use has a bug, which does not produce the correct diagrams.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Section 7.1.1 P7

  • Key: DAF-4
  • Legacy Issue Number: 19706
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    According to the description,
    "System of Systems level is not mandatory".

    This makes no sense.
    If this isn't mandatory, it is not necessary to
    define "System of Systems" here.

  • Reported: DAF 1.0b1 — Fri, 9 Jan 2015 05:00 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The description is to be modified.

    It is going to be changed as follows.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Section 7.1 P6 Figure 7-3

  • Key: DAF-3
  • Legacy Issue Number: 19705
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    There is an shared aggregation between "System of Systems" and
    "System".
    This means that subordinate parts exists independently,
    that is, Brake system (and other systems) are installed to another vehicle after
    previous one is disposed (or destroyed).
    This shared aggregation is inadequate.

  • Reported: DAF 1.0b1 — Fri, 9 Jan 2015 05:00 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The multiplicity of the figure is to be modified.

    Reflecting the comment, we changed the shared aggregation to Association. Also, the multiplicity of System of Systems is to be modified from 0..1 to 0 .. * as attached.

    For example, a smart house (system) is in cooperation with other smart houses to form a smart community (system of systems) as the whole. There would be a case that a smart house does not belong to a smart community but shares data from other smart community. In this case, the relationship between the smart house and the smart community cannot be expressed by shared aggregation, therefore we changed it to association.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

Issue Sample

  • Key: DAF-2
  • Status: closed   Implementation work Blocked
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    This is just an sample of issue.

  • Reported: DAF 1.0b1 — Wed, 14 Jan 2015 07:45 GMT
  • Disposition: Closed; Out Of Scope — DAF 1.0
  • Disposition Summary:

    It is just a sample of issue to get familiar with JIRA system. We don't need to track this issue any more.

    It is just a sample of issue to get familiar with the JIRA. So, no issue.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

DCM import SPEM2

  • Key: DAF-8
  • Status: closed  
  • Source: Information-technology Promotion Agency, Japan ( Isashi Uchida)
  • Summary:

    The xmi for the figure 7-15 (Dependability Process Model) in DCM should be imported from SPEM2 xmi.

  • Reported: DAF 1.0b1 — Tue, 27 Jan 2015 04:18 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    The figure 7-15 is to be modifed as attached.

    All calsses (WorkSequence, BreakdownElement, WorkBreakdownElement, WorkSequenceKind) from the SPEM package were prefixed with SPEM2.

    All of the classes mentioned above are now prefixed with the closest parental package name ProcessBehavior.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

BPMN XMI of DPM modifies character code.

  • Key: DAF-7
  • Status: closed  
  • Source: Information-technology Promotion Agency, Japan ( Isashi Uchida)
  • Summary:

    Character code of BPMN XMI is Shift-jis.

  • Reported: DAF 1.0b1 — Tue, 27 Jan 2015 01:55 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Fixed xmi file of BPMN

    The xmi character code of BPMN was changed to ASCII from Shit-JIS.

  • Updated: Tue, 22 Dec 2015 15:04 GMT
  • Attachments:

UML reference # issue -- F (On behalf of M. Haus)

  • Key: DAF-24
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    In section 3, UML 2.4 is specified. Any reason why not to use UML 2.5?

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:42 GMT
  • Disposition: Closed; No Change — DAF 1.0
  • Disposition Summary:

    Because UML 2.4 is an ISO standard.

    See above.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Reference issue -- E (On behalf of M.Haus)

  • Key: DAF-23
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    In Section 0.4 "This specification is compatible with other OMG and Non-OMG standards." You should specify which ones, or reference the section where they are listed.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:40 GMT
  • Disposition: Closed; No Change — DAF 1.0
  • Disposition Summary:

    *The 0 section is removed in the Beta version. *

    See above.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Attribute issue -- J (On behalf of M. Haus)

  • Key: DAF-28
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    Figure 7 8 - Sample extension of Dependability Attribute Attributes normally are a single entity. It is odd that the attribute is composed of several other elements.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:50 GMT
  • Disposition: Closed; No Change — DAF 1.0
  • Disposition Summary:

    No change to be proposed

    DAF spec already submitted has this amendment. So we would like to propose "closed and no change".

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Dependency issue -- I (On behalf of M. Haus)

  • Key: DAF-27
  • Status: closed  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    Figure 7 4 - Dependability Assurance Concept package I am surprised that there are not more dependencies between the packages.

  • Reported: DAF 1.0b1 — Fri, 27 Feb 2015 01:49 GMT
  • Disposition: Closed; No Change — DAF 1.0
  • Disposition Summary:

    All links are checked.

    We have checked all the dependency links between the packages, which are drawn in the latest version beta 1. They are correct as they are.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Section 6 needs re-labelling, rearranging

  • Key: DAF-11
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Additional Information" (Section 6) should presumably be labelled as non-normative. Section 6.5 "Changes to Adapted OMG Specifications" should be removed altogether.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:28 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Proposal to rephrase the titles for each section

    The following changes are going to be proposed as normative. Could we agree on this?

    Original :

    6. Additional Information
    6.1 Background and Rationale
    6.2 General Introduction of DAF
    6.3 Key Capabilities of DAF
    6.4 Procedure
    6.5 Changes to Adapted OMG Specifications
    6.5 How to Read this Specifications

    New :
    6. Overview of the specification
    6.1 Introduction
    6.2 Key features
    6.2.1 Key capabilities of DAF
    6.2.2 Procedure
    6.2.3 How to Read this specifications

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Reword "Suggested conformance points"

  • Key: DAF-10
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In the conformance section (section 2) of sysa/14-11-01, it's not clear what is meant by "suggested conformance points". Are these "optional conformance points"? If so, what parts of the specification is it mandatory for implementers to provide to claim conformance to the specification?

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:25 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Conformance section is to be modified

    The "suggested" indicates ambiguity for comformance point. So, we are going to remove the word "suggested" to specify mandatory conformance points.

    OLD :
    In this Dependability Assurance Framework for Safety-Sensitive Consumer Devices (SSCD) Specification, suggested conformance points are Dependability Conceptual Model, Dependability Assurance Case, and Dependability Process Model. DAC templates shall confirm to SACM.
    This specification is intended to be an umbrella specification, which allows several existing specifications/standards either by OMG or other standardization bodies in a single framework.

    For any specification/standard of a specific SSCD to be in conformance with the Dependability Conceptual Model requires that the conceptual model of the standard/specification shall include all models in DCM. It shall extend DCM specified in this specification to support new dependability, assurance and process concepts for that specific SSCD as long as it will not cause any semantic inconsistency between DCM and the new conceptual model.

    For conformance to Dependability Assurance Case, argumentation for SSCD dependability shall follow the argument structure specified in the clause 8.

    For conformance to Dependability Process Model, the development process for SSCD shall follow the process defined in clause 9.

    NEW :
    This specification is intended to be an umbrella specification, which allows several existing specifications/standards either by OMG or other standardization bodies in a single framework.

    For any specification/standard of a specific SSCD to be in conformance with the Dependability Conceptual Model requires that the conceptual model of the standard/specification shall include all models in DCM. It shall extend DCM specified in this specification to support new dependability, assurance and process concepts for that specific SSCD as long as it will not cause any semantic inconsistency between DCM and the new conceptual model.

    For conformance to Dependability Assurance Case, argumentation for SSCD dependability shall follow the argument structure specified in the clause 8. DAC shall conform to SACM.

    For conformance to Dependability Process Model, the development process for SSCD shall follow the process defined in clause 9.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

Make example time-independent

  • Key: DAF-15
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In section 8.1 of sysa/14-11-01, this sentence: "Recently, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump" should be re-phrased so that it will still make sense if read in 5 or 10 years' time.
    A reference to this example, and also to the others in this paragraph, would be very useful.

  • Reported: DAF 1.0b1 — Thu, 5 Feb 2015 17:37 GMT
  • Disposition: Resolved — DAF 1.0
  • Disposition Summary:

    Add the year 2010.

    We will change the sentence as follows

    OLD :
    Recently, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump.

    ->
    NEW :
    In 2010, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump.

  • Updated: Tue, 22 Dec 2015 15:04 GMT

SACM1.1 compliance

  • Key: DAF-76
  • Status: open  
  • Source: Toyota Motor Corporation ( Naoya Ishizaki)
  • Summary:

    SACM 1.1 is the latest SACM specification. However it does not include schema file for the sacm xmi, which makes hard to submit our DAC templates in compliance with SACM 1.1. Compling with the SACM1.0 was raised with the issue # 70. Toward RTF, compling with SACM1.1 is required.

  • Reported: DAF 1.0b1 — Fri, 31 Jul 2015 01:32 GMT
  • Updated: Fri, 31 Jul 2015 01:32 GMT

Dependability Process Model (9.2) is poor

  • Key: DAF-51
  • Status: open  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    In 9.2, there is a description of Dependability Process. However, this explanation is poor. It is insufficient.
    Besides, there is a description " System Engineerging Process", However, there isn't " System ENgineering Process" on the Figure 9-2.
    Furhermore, clause 9.3 describes the "System Engineering Process". However, its diagram is slighly different from Figure 9-2. (For example, Figure9-2 includes "Development complete" branch, on the other hand, Fig 9-3 doesn't include it. Fig 9-2 includes "artifacts", however, FIg 9-3 doesn't include those. And, its branch condifition "Development continue" is ambigous.What is " Development conitue"?

  • Reported: DAF 1.0b1 — Tue, 26 May 2015 01:20 GMT
  • Updated: Fri, 12 Jun 2015 08:28 GMT

"Dependabilty Analysis" describes only Threat Analysis,

  • Key: DAF-52
  • Status: open  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    In 9.2.1, According to the text, "Dependablity Analysis" talk about "threat" and "safety". From general definition, it is insufficient.

  • Reported: DAF 1.0b1 — Tue, 26 May 2015 01:54 GMT
  • Updated: Fri, 12 Jun 2015 08:28 GMT