Minutes of Weekly Meeting, 2010-12-10

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh Carl Walker Harrison Miles Brian Erickson Brad Van Treuren Peter Horwood Heiko Ehrenberg Eric Cormack (joined 11:15) Excused: Adam Ley Patrick Au

2. Review and approve previous minutes:

12/03/2012 minutes:

  • One correction noted in the updated draft: In 5a, change 'Harrison moved the Use Case Inheritance Tree slide...' to 'Harrison moved to the Use Case Inheritance Tree slide...'.
  • Brad moved to approve with the above amendment, seconded by Carl. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? see also Gunnar's presentation, in particular the new information he'd be looking for in a test language
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • Harrison - Supply Ian with the presentation material used today for inclusion with the draft minutes. COMPLETE

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

{Eric joined}

  1. Consider 'layers' and dependencies as they relate to Harrison's table and Brad's cube model.
    • Following on from question that Heiko had asked prior to last week's meeting on the availability of a description or diagram to help explain the Cube Model, Ian had prepared a few slides to try to illustrate the basic Object Oriented concepts behind this. As both Ian and Brad claimed to be rusty on OO methods Ian hoped they could keep each other right.
    • {Slide pack shared} ( http://files.sjtag.org/IanMc/OO_Concepts_for_SJTAG.pdf)
    • {Slide 2} The slides were heavily based on the Concepts section of the Booch book that Brad had referred to at the previous meeting (ISBN is given in the slide pack):
      http://faculty.yu.edu.jo/ahmads/DownloadHandler.ashx?pg=ab2c8108-dd77-4ca9-b22f-66553ed2cdec&section=fa16fdaf-ad83-4262-8ad7-f703f55a1b8e&file=_6dtVaEUq4sY.pdf
    • Ian hoped that the slides might also help to explain why some of the techniques we had tried to apply previously hadn't been entirely successful but noted that the material here had a software focus so there'd need to be a 'read across' into SJTAG. Brad added that since we were talking about a 'model' here it should map readily between software and SJTAG domains.
    • {Slide 3} In a complex systems it's not enough to consider only the structural hierarchy: The component parts interrelate in other ways that also need to be considered.
    • {Slide 4} On the plane at the lower right we can see 'objects' that are grouped with other objects to fulfill some function. These may in turn form part of some higher level grouping, designated by the dotted boxes. These groups and their relation to other groups can also be seen in the canonical view above. Looking at the plane to the right we see 'classes', C1-C8. The class can describe what type of thing and object is and the relationship between classes can show if a class inherits properties from a lower level class.
    • In the canonical form, some objects have been shown with a designation such as 'O3' to indicate that the object is an instance of class 'C3'. But there are three instances of 'O3' in different parts the system. This is similar to having multiple instances of the same board type in a system but not necessarily performing the same function.
    • The two planes represent two facets of the cube; there may be more. Brad added that the object structure shows what are parts of other things: This can help determine which things need to be together to operate. The class view can show how properties are related and how you may be able to exploit reuse.
    • {Slide 5} Algorithmic Decomposition is a rather natural way to break down a problem description, but it assumes a fixed hierarchy to everything and it makes it hard to spot common features across elements in the hierarchy.
    • {Slide 6} Object Oriented decomposition removes the hierarchical ordering and focuses on 'what' is being acted on (the objects) and the actions that are ocurring (the agents), but it may be more difficult to think in these terms.
    • Brad noted that there is essential analysis prior to this decomposition: It is necessary to identify the objects and then to identify the relationships between the objects. It is not a trivial task to arrive at this diagram. It is also important to avoid confusing this with a state diagram.
    • {Slide 7} Simply a reinforcement of the idea of 'perspective'. The cube model is similar to looking at a 3D object inside a glass cube: As you look in each face you see the same item, but you see different parts (or abstractions)of it. We've discussed abstractions previously, but may not have found abstractions that were truly meaningful for SJTAG.
    • Ian asked whether this had been helpful or confusing. Harrison thought it helped and thought it illustrated the idea that 'perception is a hypothesis'. Brad observer that it was possible that we had made a mistake in partitioning our Use Cases by not categorizing them properly. What we have been doing recently is to examine layers within the control domain and that is much finer grained than we have previously considered. We need the hierarchy of primitive that will form our building blocks, and we need those building blocks for the standard.
    • Heiko felt that the slides had at least given him an idea of what the cube was meant to show.
    • Ian wondered if that affected the work Harrison had been doing on 'layers'. Brad thought it showed that we had to consider more than just the hardware - How are states related to the Use Cases? We can perform some Use Cases only at particular times and power conditions. It's more than just the dependencies that we have been discussing recently, and this was maybe what Harrison was touching on in comparing BIOS test versus Firmware test versus Application level test. Harrison agreed that these were all crossing boundaries of knowledge and levels of observability. Brad added that there was also the matter of how much of the board was operational. Brad felt it might be beneficial for the group to consider a set of tables, beginning with the one Harrison had started:
      (1) Dependency of hierarchical capabilities (essentially physical)
      (2) Operational status (when it can be run) - there are 7 states identified by industry, 4 identified by SJTAG.
      (3) How much of the board needs to be operational for the Use Case to function: Some things may be easier if delegated control is possible. Harrison added that some things may need to be locally aware as a board may not be sentient enough to collect data from somewhere central. Brad agreed that there was a dependency on test architecture: A multidrop makes for difficulty in consolidating the testing and result collection back to a system controller. Harrison summarized this as 'If I want to do a structural test then I want make it local else bad things happen.'
      (4) Relationship: What can be done in different architectures?
      (5) Product lifecycle: If we want to do structural test on board then how do we set up a manufacturing process that uses that efficiently.
      Harrison felt he already had some of that information and would supply it. Brad suggested that the minutes of the meeting should include a link to the source document used for the slides. Ian agreed, but felt that most people probably only needed to refer to the 'Concepts' section.

6. Key Takeaway for today's meeting

  1. Five tables for future consideration:
    (1) Dependency of hierarchical capabilities
    (2) Operational status (when it can be run?)
    (3) How much of the board needs to be operational?
    (4) Relationship: What can be done in different architectures?
    (5) Product lifecycle.

7. Schedule next meeting

Next Meeting:
December 17. Brad expects to miss.

January schedule:
7 Brian expects to miss.
14
21
28

8. Any other business

  • The WG officers will need to be reaffirmed in the New Year.
  • The recirculation ballot for 1149.1 closes today.

9. Review new action items

  • Ian - Provide the slides used today and a link to the original PDF source.

10. Adjourn

Brad moved to adjourn at 11:57 AM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh