1. HLA Product Support Group Interim Meeting 27 March 2012 Simulation Interoperability Standards Organization

2. 2 Agenda Intro & Administration - Approval of minutes of last meeting Existing Comments New Business Standard Revision Adjourn

3. 3 Step 5 : Interpretation, Distribution and Configuration Management Responsibility of SAC and Product Support Group Establish and maintain a process to respond to questions concerning the language used in the standard, the intention or result meant by a particular action, or an explanation of the reasons behind what the standard says. Establish and maintain a Help Desk function using the SISO provided discussion board to answer questions and provide support to the community. Establish and maintain a Problem/Change Request process to collect problems and change requests from the community. Conduct analysis and refinement of submitted problems and change requests. When the PSG is operating in parallel with a PDG developing a revision to a product, forward refined PCRs to the PDG for use in revision development. Maintain liaison with related Conference Forums, related PDGs, related PSGs, and related SGs. Identify, create, and maintain SISO reference products relating to the balloted products being supported. Identify and create Product Nominations for additional parts or supplements.

4. 4 * Abstentions do not count as votes PSG Voting Rules - 1 Applies to general PSG business and comment resolution Face-to-face and teleconference Voting - Minimum of a five-person quorum required to conduct a vote - All PSG members present are eligible to vote - PSGs with restrictive memberships (additional qualifications to the ones listed in BPDSP) may establish a quorum requirement (with SAC approval) based on a percentage of members - 67% of members present must vote* - 75% consensus of members present who vote* required to approve a motion - If a 75% consensus cannot be reached, the issue is moved to an electronic vote.

5. 5 PSG Voting Rules - 2 Electronic Vote - PSG Chair may require an electronic vote on any issue - PSG Secretary posts a summary of the related discussion on the PSG reflector Notice of an electronic vote shall be posted at least 10 business days in advance and the voting shall remain open for five days - After announced period of time for discussion, electronic vote is held to allow the complete PSG to vote on the issue - An electronic vote must have at least five (5) voters PSGs with restrictive memberships (additional qualifications to the ones listed in BPDSP) may establish a quorum requirement based on a percentage of members with SAC approval - Electronic votes are carried by majority (50% plus one) of votes cast

6. 6 PSG Voting Rules - 3 Recall of Face-to-Face or Teleconference vote results - Issues approved by 75% consensus at a face-to-face meeting or teleconference shall be posted to the reflector within five days - PSG members not present for the vote shall have 10 days from the posting to recall the issue - Ten recall petitions shall require an electronic vote Officer voting - PSG Chair, or acting PSG Chair Does not vote in face-to-face meetings or teleconferences Is not counted toward a quorum - PSG Chair may cast the deciding vote in electronic votes - Other PSG officers may vote in face-to-face, teleconference and electronic votes

7. Existing Comments COM_1Referencing 1516-2009 instead of 1516-2010 COM_2Reference to wrong item in list COM_3Inconsistency in Register Object Instance service COM_4The MOM (Management Object Model) portion of the HLA Standard MIM file does not conform to what is stated in the specifications. COM_5There is an inconsistency in the mapping between the specifications and the APIs. Some of the APIs are missing exceptions in their global declaration lists, or in lists for specific HLA service calls. In addition many of the APIs have exceptions related COM_6When an RTI callback has a set of attribute designators as a parameter, the spec is ambiguous. Must the RTI send all applicable attributes in a single callback or may it stagger them over multiple callbacks? 7

8. COM_1 COM_1 - Referencing 1516-2009 instead of 1516-2010 Page Number: page 295, Line Number: 12.11.1, s Problem: The RTI shall provide the HLA 1516-2009.1 Java API classes in the package hla.rti1516e with corresponding subpackages. Action: The RTI shall provide the HLA 1516-2010.1 Java API classes in the package hla.rti1516e with corresponding subpackages. IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: Editorial Change Disposition Code: BRC Type Code: EC - Editorial Change Response: Status Code: OP Date Last Updated: 10/31/2011 Resolution: Submitted by: Martin Johansson on 10/31/2011 as a Editorial Change 8

9. COM_2 COM_2 - Reference to wrong item in list Page Number: page 350, Line Number: E.5.1.2 Problem: Recall the wording of item (o) of 5.1.2, which says, An update to an instance attribute by the federate that owns that instance attribute shall be reflected only by other federates that are subscribed to the instance attributes corresponding class attribute at the known class of the object instance that contains that instance attribute at the subscribing federate. But item it is probably item (s) in 5.1.2 that should be referenced here. Action: Reference to (s) instead and update the quote IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: Editorial Change Disposition Code: BRC Type Code: EC - Editorial Change Response: Status Code: OP Date Last Updated: 10/31/2011 Resolution: Submitted by: Martin Johansson on 10/31/2011 as a Editorial Change 9

10. COM_3 COM_3 - Inconsistency in Register Object Instance service Page Number: IF Spec Line Number: 6.8 Regist Problem: This text should also mention the new Multiple Object Instances Names Reserved service as a way to reserve names. Action: New text: If the optional object instance name argument is supplied, that name shall have been successfully reserved by the registering federate as indicated by the Object Instance Name Reserved service or Multiple Object Instance Names Reserved service and shall be coadunated with the object instance. If the optional object instance name argument is not supplied, the RTI shall create a federation execution-wide unique name, and that name shall be coadunated with the object instance. IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: Editorial Change Disposition Code: BRC Type Code: EC - Editorial Change Response: Status Code: OP Date Last Updated: 1/9/2012 Resolution: Submitted by: Bjorn Moller on 1/9/2012 as a Editorial Change 10

11. COM_4 COM_4 - The MOM (Management Object Model) portion of the HLA Standard MIM file does not conform to what is stated in the specifications. Page Number: HLAstandar Line Number: 910 Problem: IEEE HLA 1516.1-2010 chapter 11.3 table 5 specifies the MOM interaction class table structure. The class HLAadjust contains three subclasses, HLAsetTiming, HLAmodifyAttributeState and HLAsetSwitches. In table 17, the parameters HLAserviceReporting and HLAexceptionReporting are defined for HLAsetSwitches. This means that in order for a federate to request that the RTI send service or exception reports to it, the interaction class HLAsetSwitches must be sent with those parameters set to "true". In the HLAstandardMIM, interaction class HLAsetSwitches does not contain those two parameters. Instead, there are two extra classes defined as children of HLAadjust, HLAsetServiceReporting and HLAsetExceptionReporting. This means that in order for a federate to request that interactions or exceptions be sent, it must send one of those two interactions with the parameter HLAreportingState set to "true". Action: Suggested Resolution or Action to be Taken: The file HLAstandardMIM.xml should be changed to reflect how it's defined in the specification. Specifically, the interaction class HLAsetSwitches must have two parameters added to it, HLAserviceReporting and HLAexceptionReporting. The classes HLAserviceReporting and HLAexceptionReporting must be removed. 11

12. COM_4a IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: Minor Technical Change Disposition Code: BRC Type Code: CC - Minor Technical Change Response: Status Code: OP Date Last Updated: 3/27/2012 Resolution: Submitted by: Joseph Bondi on 3/27/2012 as a Minor Technical Change 12

13. COM_5 COM_5 - There is an inconsistency in the mapping between the specifications and the APIs. Some of the APIs are missing exceptions in their global declaration lists, or in lists for specific HLA service calls. In addition many of the APIs have exceptions related Page Number: 4.5.5, 4.9 Problem: - The specification is missing the exceptions "Error reading FOM module" and "FOM inconsistent with the current FDD" for the Create Federation Execution service, which are present in the corresponding APIs. - The Join Federation Execution service exception "Inconsistent FOM module" is ambiguous, as it is unclear from the wording in the specification whether the inconsistency is within the module, or between the module and the current FDD resulting from the MIM and the currently-loaded FOM modules. - There is an exception ordering error between the Join Federation Execution service exceptions "Invalid FOM module" and "Inconsistent FOM module". - The Join Federation Execution service is missing an "Error reading FOM module exception" that is present in the corresponding APIs. - In the Java and C++ APIs, the InvalidMIM and InvalidFOM classes that correspond to the "Invalid MIM" and "Invalid FOM module" exceptions in the specification are missing, and exceptions related to the FOM have the suffix "FDD" which is inconsistent with the "FOM" suffix used in the corresponding specification exceptions. - The mapping between the FOM and MIM exceptions in the specification and the corresponding APIs is ambiguous. 13

14. COM_5a Action: Section 4.5.5, page 40: Shift the exceptions (c) through (i) down to become exceptions (d) through (j), and replace the old (c) with the exception "Error Reading FOM" and; then shift exceptions (g) through (j) down to become exceptions (h) through (k) and replace the old (g) with the exception "Error Reading MIM" and; shift the exceptions (b) through (k) down to become exceptions (b) through (l) and replace the old (b) with the exception "FOM module inconsistent with current FDD"; the resulting exception list follows: a) Could not create logical time implementation. b) FOM module inconsistent with current FDD. c) Invalid FOM module. d) Error reading FOM module. e) Could not locate FOM module indicated by supplied designator. f) MIM designator shall not be HLAstandardMIM. g) Invalid MIM. h) Error reading MIM. i) Could not locate MIM indicated by supplied designator. j) The specified federation execution already exists. k) Not connected. l) RTI internal error. " Section 4.9.5, page 43: Replace (e) with "FOM module inconsistent with current FDD"; swap the positions of exceptions (d) and (e); shift exceptions (f) through (k) down to become exceptions (g) through (l) and replace the old (f) with "Error reading FOM module"; the resulting exception list follows: " a) Could not create logical time implementation. b) Federate name already in use. c) The specified federation execution does not exist. d) FOM module inconsistent with current FDD. e) Invalid FOM module. f) Error reading FOM module. g) Could not locate FOM module indicated by supplied designator. h) Federate save in progress. i) Federate restore in progress. j) The federate is already joined to the federation execution. k) Not connected. l) RTI internal error. " 14

15. COM_5b Java API: Add an InvalidMIM exception class and add it before ErrorReadingMIM to the throws declaration lists for the createFederationExecution service methods that have "mimModule" as a parameter; Add an InvalidFOM exception class and add it before ErrorReadingFDD to the throws declaration lists for the createFederationExecution service methods and the joinFederationExecution service methods that have "additionalFOMModules" as a parameter; Rename the following exception classes and all associated references to them according to rules below: 1. "CouldNotOpenFDD" becomes "CouldNotOpenFOM". 2. "ErrorReadingFDD" becomes "ErrorReadingFOM". 3. "InconsistentFDD" becomes "InconsistentFOM". C++ API: Add an InvalidMIM exception class and add it before ErrorReadingMIM to the throws declaration lists for the createFederationExecution service methods that take "mimModule" as a parameter; Add an InvalidFOM exception class and and add it before ErrorReadingFDD to the throws declaration lists for the createFederationExecution service methods and the joinFederationExecution service methods; Rename the following exception classes and all associated references to them according to the table below: 1. "CouldNotOpenFDD" becomes "CouldNotOpenFOM". 2. "ErrorReadingFDD" becomes "ErrorReadingFOM". 3. "InconsistentFDD" becomes "InconsistentFOM". 15

16. COM_5c Section 12.11.5.3, page 302: Add the paragraph: "The following table shows the mapping between the Java implementation of HLA exceptions and the exceptions listed in Sections 4.5.5 and 4.9.5:" Add a table having the column headings "HLA Exception", "Java Exception", and "Interpretation", and the following rows: HLA Exception: "Could not locate MIM indicated by supplied designator" Java Exception: "CouldNotOpenMIM" Interpretation: "An error occurred when attempting to acquire the MIM resource in preparation for reading. The resource referenced by the designator may not exist, may be unreachable due to restricted permissions or network errors, or may be unavailable to be acquired for reading for any other reason." HLA Exception: "Error Reading MIM" Java Exception: "ErrorReadingMIM" Interpretation: "An error occurred when attempting to physically read data from the MIM resource. The resource referenced by the designator was successfully acquired for reading, but an error occurred during the data read process, preventing the data from being fully read. The error may be due to a file-system or network error, or any other reason preventing the data from being physically read from the resource by the underlying system." HLA Exception: "Invalid MIM" Java Exception: "InvalidMIM" Interpretation: "The MIM resource does not satisfy the requirements in Annex G." 16

17. COM_5d HLA Exception: "Could not locate FOM module indicated by supplied designator" Java Exception: "CouldNotOpenFOM" Interpretation: "An error occurred when attempting to acquire the FOM module resource in preparation for reading. The resource referenced by the designator may not exist, may be unreachable due to restricted permissions or network errors, or may be unavailable to be acquired for reading for any other reason." HLA Exception: "Error Reading FOM module" Java Exception: "ErrorReadingFOM" Interpretation: "An error occurred when attempting to physically read data from the FOM module resource. The resource referenced by the designator was successfully acquired for reading, but an error occurred during the data read process, preventing the data from being fully read. The error may be due to a file-system or network error, or any other reason preventing the data from being physically read from the resource by the underlying system." HLA Exception: "Invalid FOM module" Java Exception: "InvalidFOM" Interpretation: "The FOM module resource does not satisfy the requirements in Annex F." HLA Exception: "Inconsistent FDD" Java Exception: "InconsistentFDD" Interpretation: "The FDD composed from the FOM module and the current FDD is not consistent with the requirements in Annex F." 17

18. COM_5e Section 12.12.6.3, page 318: Add the paragraph: "The following table shows the mapping between the C++ implementation of HLA exceptions and the exceptions listed in Sections 4.5.5 and 4.9.5:" Add a table having the column headings "HLA Exception", "C++ Exception", and "Interpretation", and the following rows: HLA Exception: "Could not locate MIM indicated by supplied designator" C++ Exception: "CouldNotOpenMIM" Interpretation: "An error occurred when attempting to acquire the MIM resource in preparation for reading. The resource referenced by the designator may not exist, may be unreachable due to restricted permissions or network errors, or may be unavailable to be acquired for reading for any other reason." HLA Exception: "Error Reading MIM" C++ Exception: "ErrorReadingMIM" Interpretation: "An error occurred when attempting to physically read data from the MIM resource. The resource referenced by the designator was successfully acquired for reading, but an error occurred during the data read process, preventing the data from being fully read. The error may be due to a file-system or network error, or any other reason preventing the data from being physically read from the resource by the underlying system." HLA Exception: "Invalid MIM" C++ Exception: "InvalidMIM" Interpretation: "The MIM resource does not satisfy the requirements in Annex G." 18

19. COM_5f HLA Exception: "Could not locate FOM module indicated by supplied designator" C++ Exception: "CouldNotOpenFOM" Interpretation: "An error occurred when attempting to acquire the FOM module resource in preparation for reading. The resource referenced by the designator may not exist, may be unreachable due to restricted permissions or network errors, or may be unavailable to be acquired for reading for any other reason." HLA Exception: "Error Reading FOM module" C++ Exception: "ErrorReadingFOM" Interpretation: "An error occurred when attempting to physically read data from the FOM module resource. The resource referenced by the designator was successfully acquired for reading, but an error occurred during the data read process, preventing the data from being fully read. The error may be due to a file-system or network error, or any other reason preventing the data from being physically read from the resource by the underlying system." HLA Exception: "Invalid FOM module" C++ Exception: "InvalidFOM" Interpretation: "The FOM module resource does not satisfy the requirements in Annex F." HLA Exception: "Inconsistent FDD" C++ Exception: "InconsistentFDD" Interpretation: "The FDD composed from the FOM module and the current FDD is not consistent with the requirements in Annex F." 19

20. COM_5f IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: Minor Technical Change Disposition Code: BRC Type Code: CC - Minor Technical Change Response: Status Code: OP Date Last Updated: 3/27/2012 Resolution: Submitted by: Joseph Bondi on 3/27/2012 as a Minor Technical Change 20

21. COM_6 COM_6 - When an RTI callback has a set of attribute designators as a parameter, the spec is ambiguous. Must the RTI send all applicable attributes in a single callback or may it stagger them over multiple callbacks? Page Number: 6.11, 6.17 Problem: In all of the specifications for HLA, there are callbacks that allow the RTI to send a set of attribute designators to a federate. There is nothing in the specifications that determines that the attributes must be sent in a single set, and leaves it open for interpretation if they may be split into two or more smaller sets. This can be an issue if several attributes fulfill the criteria to be sent as a callback, there is a choice whether to implement this as being sent in a single callback, or multiple ones. For example, if a federate is requesting the scope of a series of 5 attributes, the RTI can send all 5 in a single callback, one each in 5 separate callbacks, or any combination thereof. This can cause a federate to malfunction if it is coded to expect a single callback and the RTI makes many callbacks. The federate has no way to know when the multiple callbacks have been completed, and must receive the entire set in a single callback. Detailed below are the areas in the specification where the ambiguity is relevant. 21

22. COM_6a Action: Section 6.11, page 101: Add the paragraph: All the instance attribute/value pairs in an Update Attribute Values service invocation for instance attributes that have identical transportation and message-ordering types shall be in one corresponding Reflect Attribute Values service invocation. This implies that one Update Attribute Values invocation could result in multiple Reflect Attribute Values invocations in a subscribing federate. Section 6.17, page 109: Add the paragraph: All the attributes of one object instance that are in scope for the federate shall be in one Attributes in Scope service invocation. Section 6.18, page 110: Add the paragraph: All the attributes of one object instance that are out of scope for the federate shall be in one Attributes out of Scope service invocation. Section 6.20, page 112: Add the paragraph: All the attributes listed in a single Request Attribute Value Update shall be in one Provide Attribute Value Update service invocation. Section 6.24, page 116: Add the paragraph: All the attributes listed in a single Request Attribute Transportation Type Change service call shall be in one Confirm Attribute Transportation Type Change service invocation. 22

23. COM_6b Section 7.4, page 132: Add the paragraph: All the attributes specified in a single Negotiated Attribute Ownership Divestiture or Unconditional Attribute Ownership Divestiture service calls shall be in one Request Attribute Ownership Assumption service invocation. Section 7.5, page 133: Add the paragraph: All the attributes specified in a single Negotiated Attribute Ownership Divestiture or Unconditional Attribute Ownership Divestiture service calls shall be in one Request Divestiture Confirmation service invocation. Section 7.7, page 135: Add the paragraph: All the attributes of a single Confirm Divestiture service call shall be in one Attribute Ownership Acquisition Notification service invocation. Section 7.10, page 139: Add the paragraph: All the attributes listed in an Attribute Ownership Acquisition or Attribute Ownership Acquisition if Available service call shall be in one Attribute Ownership Unavailable service invocation. Section 7.11, page 140: Add the paragraph: All the attributes requested for the specified object in the Attribute Ownership Acquisition service invocation shall be in one Request Attribute Ownership Release service invocation 23

24. COM_6c Section 7.16, page 145: Add the paragraph: All the attributes requested for the specified object in the Cancel Attribute Ownership Acquisition service invocation shall be in one Confirm Attribute Ownership Cancellation service invocation IEEE WG Ballot Item Resolution Rank: Official Balloter's Type Code: General Change Disposition Code: BRC Type Code: GC - General Change Response: Status Code: OP Date Last Updated: 3/27/2012 Resolution: Submitted by: Joseph Bondi on 3/27/2012 as a General Change 24

25. Possible Comments for HLA Evolved 1.Additional FOM Module merging semantics 2.Connect service parameter (LSD) 3.OMT – Tables or XML 4.Minor OMT Schema tweaks 5.Format for OMT glyph For discussion. Collecting community input.

26. 1. Additional FOM Module Merging Semantics The general principle for merging FOM modules is “union” Example: Module A has data type D1, D2 Module B has data type D2, D3 Merged result has data type D1, D2, D3 D2 has to have identical definitions

27. Merging Object Classes HLAObjectRoot TrackSegment Signal Train HLAObjectRoot Train CargoTrain HLAObjectRoot TrackSegment Signal Train CargoTrain Scaffolding Definition Railbase FOM Module Cargo FOM Module Resulting FOM

28. Suggested Improvement - 1 Merge attributes for a given class Aircraft - Marking - Spatial Aircraft - Marking - Spatial Aircraft - Marking - DamageState Aircraft - Marking - DamageState Aircraft - Marking - Spatial - DamageState Aircraft - Marking - Spatial - DamageState U = Module AModule BResult

29. Suggested Improvement - 2 Merge dimensions for a given attribute or interaction Aircraft.spatial Dimensions: - Lat - Long Aircraft.spatial Dimensions: - Lat - Long Aircraft.spatial Dimensions: - Country Aircraft.spatial Dimensions: - Country Aircraft.spatial Dimensions: - Lat - Long - Country Aircraft.spatial Dimensions: - Lat - Long - Country U = Module AModule BResult

30. Impact on existing implementations Existing federates and their FOM modules that use HLA 1516-2010 will still work the same way. No need to change. Existing RTIs and OMT tools (and tools that merge FOM modules) will need to be modified to support the new merging rules.

31. 2. Connect Service Parameter (LSD) When calling the Connect service a Local Settings Designator parameter can be provided. Allows for programmatic selection of connection parameters. Actual string content is RTI specific. May in some cases require a federate deloper to adapt his federate to a particular RTI. Is this a problem? Should we standardize further?

32. Sample LSD Usage Connect(“”)  Use default settings file (RID) Connect(“WANconfig”)  Use particular settings file Connect(“CRChost=192.168.3.4”)  Override setting programatically Connect(“WANconfig\nCRChost=192.168.3.4 ”)  Both of the above

33. 3. OMT – Tables or XML? Currently the authoritative format for OMT is tables. We then try to mimic this using XML for the actual saving of FOMs. Since tables and XML are inherently different this creates a bigger and bigger gap between how it prints (tables) and what it really is (XML). Is it time to make XML the primary format and to make the tables a recommended pretty-printing format?

34. 4. Minor OMT Schema Tweaks 4a: If you have an empty string as a value for certain fields then you cannot put a Note on it. 4b: Some Schemas are too restrictive. The FDD Schema checks whether your identification table is OK, which is not really required by the text in the standard

35. 5. OMT Glyph (icon) format The OMT glyph can be a picture in any format, GIF, JPG, Nikon D400 Raw, Commodore 64 Sprite or whatever. This is a challenge for OMT tools! Should we limit this to popular Internet formats like GIF, JPG and PNG only? Should we specify or recommend any particular pixel size? Most operating systems using icons do this.

36. Open Floor 36

37. 37 Step 6 : Periodic Review Conduct Periodic Reviews Determine course of action for SISO Product(s) - Reaffirm - Revise - Withdraw IEEE expectation is action around 2015, revision does not need to take 5 years.

38. Backup Slides 38

39. 39 SISO Operating Principles Responsiveness and Responsibility - SISO shall be responsive to the communities it serves. SISO shall be responsible for providing products and services that promote interoperability and reuse with the least possible impact on existing applications. Quality - SISO activities and resulting products shall reflect technical excellence and the highest quality work. Discipline - SISO shall exercise due process in all activities. Policies and procedures shall be publicly available and shall serve as the basis for governing the organization and its activities. SISO standards development processes shall have a balance of interests and shall not be dominated by any single interest category Fairness - SISO activities shall provide the right of appeal at all levels. Openness - SISO activities shall be carried out in an open forum where any person has access to the process. Consensus - SISO decisions shall be based on simple majority agreement unless explicitly stated otherwise. Votes and ballots can be conducted in person, by teleconference, or by electronic balloting, as appropriate.

40. 40 SISO Technical Acceptance Principles Relevant - SISO Products will be relevant to the Modeling and Simulation Community. Substantive - SISO Products shall provide meaningful information and/or results. Timely - SISO Products will be produced in an efficient manner to ensure that the product is useful to the community. Community Review & Acceptance - SISO Products will be reviewed by the technical community to which the product applies. This may be a narrow niche or the community broadly defined.

41. 41 SISO Balloted Product Principles Generality - Standards Products shall be as general as possible, while still maintaining usefulness, to support the broadest community of current and future users. Stability - Standards Products shall be established and changed only as necessary. They shall be prototyped and tested before being proposed for adoption to demonstrate their maturity. Supportability - Standards Products shall maintain the integrity of the existing product suite and the needs of the user.

42. 42 Balloted Products Development and Support Process (BPDSP) BPDSP provides direction on the support of SISO balloted products; does not cover non-balloted products Builds on SISO Policies & Procedures Provides specific SAC guidance Is a comprehensive document PSG guidance based on concepts developed by DIS SSG PSG guidance developed by SAC to balance formalism and flexibility BPDSP is currently drafted and under review by SAC Every PSG does not have to “reinvent” the process

43. 43 Six Step Process You Are Here

44. 44 Appeals - 1 PSG member may appeal any decision by the PSG Chair to a vote by the PSG All PSG votes subject to appeal to the SAC - PSG member may appeal to the SAC, via the TAD, the result of a vote within five days of the vote being posted to the reflector - Classified as procedural or technical Procedural if PSG member feels the PSG violated SISO, SAC, or PSG rules or principles Technical if the PSG member believes the approved approach is not the best solution - SAC reviews the appeal and notifies the person who appeals and the PSG Chair of its decision and rationale no later than 30 days after the appeal was filed. If a resolution to the appeal cannot be reached within 30 days due to the scope of the appeal, the committee Chair will periodically post status of the appeal to the appropriate committee reflector.

45. 45 Appeals - 2 Any member of the PSG may appeal the SAC’s decision on the appeal to the EXCOM - Appealing member shall notify the SAC Chair of the appeal and the reason and rationale of the appeal - SAC Chair will provide the appeal package, the SAC decision and rationale, and the new appeal request to the EXCOM Chair - EXCOM reviews the appeal and notifies the SAC of its decision and rationale no later than 30 days after the appeal was filed SAC shall notify the person who appeals and the PDG Chair - Decisions by the EXCOM are final.

46. 46 Dominance and Affiliation All Standards Bodies are having to address the potential of dominance of the standards process The IEEE has established requirements for the disclosure of affiliation for all IEEE Working Group members - Employer - Parent Company Any allegation or evidence of dominance within a working group is reported to the IEEE Standards Activity Board SISO has tradition of levying requirements over and above IEEE

47. 47 Dominance and Affiliation All members of SISO Groups participating in the standards development process will disclose affiliation at all meetings: - Employer - Parent Company or Prime Contractor - Sponsoring Agency - Program or Product Supported