Minutes of Weekly Meeting, 2017-01-25

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Peter Horwood
Carl Walker
Brian Erickson
Brad Van Treuren

By Proxy:
---

Excused:
Heiko Ehrenberg
Bill Eklow
Adam Ley

2. Review and approve previous minutes:

  • Approval of January 11 minutes (2nd updated draft circulated on 01/18/2017)
    • No further amendments.
    • Brad moved to approve, seconded by Eric. No objections or abstentions.
  • Approval of January 18 minutes (draft circulated on 01/18/2017)
    • No corrections.
    • Eric moved to approve, seconded by Brad. 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)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • All - Propose a form of words to define "a system". COMPLETE (see Discussion Topics)

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

a. Definition of "a system".

  • Ian shared the contents of the recent email exchange on this topic:
    • Ian:
      System - An organised collection of components or assemblies that are designed to operate together to perform one or more tasks or functions.
      • This may be typified by, e.g., a rack assembly consisting of several cards mounted on a backplane. (could add other examples)
    • Heiko:
      Do we need to consider the software running on the system as part of the "system" definition?
    • Peter:
      Generic is better : A "component"  definition may or may not be capable of running software...
      • Another example may be a PCB with plugable modules.
    • Brad:
      The notion of "Field Replaceable Unit" comes to mind as possibly the smallest "System" in the EcoSystem for SJTAG as a delineation point.  It would be purely artificial, but would cover what Peter was talking about, I think.  For Ian's environment, it may be a black box.  For Carl, it may be a single router/switch in one case and a board in a shelf in another.  For an ATCA installation, it may be an AMC module that is plugged into an ATCA Carrier.
      • Then that FRU may or may not contain software to be able to run autonomously, but it could be tested stand-alone.  It is a production part of the inventory of the bigger system; software and hardware combined.
  • Ian liked the FRU notion but wasn't sure that the concept of what was a "Replaceable Unit" would be all that clear, noting that rather than FRU, his industry tended use terms like LRU (Line Replaceable Unit, e.g. an item that get replaced on the aircraft by first line repair) and SRU (Shop or Service Replaceable Unit, e.g. a pluggable module within a LRU that gets replaced by second line, in-country support).
  • Brad saw FRU as being something replaced at the customer site, so equivalent to Ian's LRU. If you think of FRUs as the "system" then you don't need to consider other things. Brad wasn't convinced that we needed to have a definition of "system".
  • Peter noted that FRU could be a single PCB assembly, and Brad added that it could be a plug-in module on a PCB. The key thing is that it represented the level you would diagnose to - you can't change a component in the field.
  • Brad agreed that the term FRU may not be clear - it is in terms of the customer perspective. The FRU is the smallest "system"; the PCB is not the "system".
  • Ian was confused because we didn't seem to be comparing like with like. Ian's FRU would the box/crate removed from the aircraft (LRU) rather than the module (SRU) but in Brad's case it seemed to be that a module within a rack was the FRU. Brad agreed but explained that his top level system might consist of racks of communications equipment, base stations, antennae, etc., but the replaceable module is the level that you'd diagnose to in the field. Similarly, for Ian's case, a whole radar system would not be removed from the aircraft, only the suspect unit, e,g, a receiver. In either case, the removed unit would have some level of diagnostic capability that would then allow fault finding to a lower level without the need for the remainder of the greater "system".  Ian accepted that and noted that often an entire submarine or aircraft may be called a system.  Brad expressed the opinion that the concept of a system was somewhat artificial.
  • Ian tried to check whether the Glossary already had a definition "FRU" but the SJTAG wiki was not working (apparent problem with webserver).  Ian was fairly sure there was a definition there, and that there may also be one for "system". 
    • [Post meeting note] The wiki became available just after the meeting closed. The following definitions existed:
      • Field Replaceable Unit (FRU) - At field service, an FRU is the level of sub-assembly that would normally be exchanged to effect a repair, the FRU subsequently being returned to a service depot for repair. Equivalent terms, for the purposes of SJTAG discussions, may include LRU (Line Replaceable Unit) and SRI (Shop Replaceable Item).
      • System - For the purposes of SJTAG, a system may be described as an aggregation of electronic circuit boards which together perform a function or range of functions.
  • Peter felt that a generic definition was best as it depended on perspective and too definitive a definition could become verbose and possibly restrictive in  terms of a PAR. Eric agreed fully with this view.
  • Eric ventured that he didn't really feel that software ought to be considered within the definition. Ian tended to agree but noted that there may be cases where software is needed to support a particular communications link or, as seems to be the case with some Intel devices, is necessary just to get hardware operational enough to do anything. Brad agreed that "it depends", and commented that some software plans will refer to the software as the system without any consideration of the hardware that it will run on, and it was primarily the hardware that we were aiming to test, not the software.  The group agreed that operational software was not something that needed to be considered and the software that may be required to support test was not necessarily operational software anyway. The software deployed on equipment in the field was not something we necessarily needed to cover.
  • Eric suggested that if ten people were asked to define a system there would be ten different answers, but felt that Ian's original proposal captured most of the aspects we felt we needed. Brad commented that it mentioned "a collection" and that was important.
  • In conclusion, it was felt that Ian's proposed definition adequately addressed what a system was in a suitably generic way, and it was agreed that no examples were necessary.

b. Building Blocks.

  • [Not discussed due to lack of time]

6. Topic for next meeting

  • Building Blocks.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • System: An organised collection of components or assemblies that are designed to operate together to perform one or more tasks or functions.
  • Carried over:
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'
    • Need a refined definition of "system" for the purposes of the PAR.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting February 1.
  • February schedule:
    • 8, 15, 22.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn, seconded by Brad.
  • Meeting adjourned at 11:56 AM EST

Respectfully submitted,
Ian McIntosh