Balisage Paper: XForms User Interfaces for Small Arcane Nontrivial Datasets

PMI Conformance Test Suite

Product and Manufacturing Information (PMI) specifies, in a formal and precise language, a product’s functional and behavioral requirements as they apply to production. PMI communicates allowable product geometry variations (tolerances) in form, size, and orientation. PMI annotations include Geometric Dimensioning and Tolerancing, surface texture specifications, finish requirements, process notes, material specifications, and welding symbols [6]. The American Society of Mechanical Engineers (ASME) defines standards for PMI within the United States [7,8], and these standards are complex. If the software applications interpreting PMI do not conform to the standards, the same PMI data is likely to be interpreted and presented differently by different engineering and manufacturing applications. Incorrect presentation and misinterpretation of PMI can cause significant delays and costly errors. For example, an Aberdeen Group study showed that catching PMI anomalies up front provides substantial savings to manufacturers in both time to market and product development costs. One large aerospace supplier reported that, prior to modernizing and improving their engineering processes, more than 30% of their change orders were due to inaccurate PMI [9].

Figure 1 shows the definition for the flatness tolerance symbol (a parallelogram), one of many PMI constructs defined in the ASME standards. The source of this figure is ISO 1101 [10], an International Standard aligned with the ASME PMI standards. When associated with a value t, specifying a flatness tolerance on a surface in a product model says that the actual surface of the manufactured part has to be contained within two parallel planes t units apart. Unless otherwise specified in the part model or drawing, all units are in millimeters.

Figure 1

Flatness tolerance symbol as defined in ISO 1101.

Figure 2 shows a two-dimensional (2D) presentation of a part model with PMI. The PMI includes a flatness tolerance of 2 millimeters, shown inside a dashed box on the upper left superimposed on the model. The part model's PMI includes numerous other PMI specifications containing different tolerance symbols, as well as additional PMI symbols.

Figure 2

2D presentation of a machined bar part annotated with PMI. Inside the dashed box is a flatness tolerance with t = 2. A leader line associates the tolerance with the surface labeled with datum feature symbol A.

The PMI conformance test suite consists of a collection of test cases for determining whether computer-aided design (CAD) software correctly implements a representative set of PMI concepts as defined in the ASME Y14.5 Dimensioning and Tolerancing [7] and Y14.41 Digital Product Data Definition Practices [8] standards. The test cases are PMI-annotated 2D isometric drawings collectively representing the machined bar part shown in Figure 2 plus four other distinct parts. There are currently a total of fifty-five test cases: fifty of them atomic and five of them complex. An Atomic Test Case (ATC) highlights an individual PMI concept to be tested, called the measurand. The ATC is not a complete specification of the part’s PMI, but rather contains only the PMI needed to specify enough context information to understand the measurand. The machined bar part in Figure 2 includes multiple ATCs. A Complex Test Case (CTC) is a test case whose PMI is a superset of the PMI of all ATCs associated with that part. Each CTC specifies one of the five distinct parts. Thus, Figure 2 is one of five CTCs.

Figure 3 presents a UML conceptual model of the PMI conformance test suite. A TestCase is an abstract (non-instantiable) class whose drawing attribute points to the location of a 2D PMI-annotated part model. A ComplexTestCase is a TestCase with an additional attribute units specifying whether dimensions are in metric or English units. An AtomicTestCase is a TestCase with additional attributes identifying its PMI category, the PMI specification being tested (with PMI symbols represented as Unicode characters), and a prose description of the measurand. Every ComplexTestCase is associated with many AtomicTestCases. Every AtomicTestCase is associated with a single ComplexTestCase^*.

Figure 3

Test case browser conceptual model.

The PMI subject matter expert who created the test cases provided two spreadsheets to document test suite metadata, examples of which include the association links and attribute values shown in Figure 3. The first spreadsheet provided metadata for each CTC as shown in Table I. Each row corresponds to one of the five CTCs. The first row provides metadata for the machined bar CTC whose drawing was shown in Figure 2. The second spreadsheet provides metadata for each of the fifty ATCs. Table II shows an example row from this spreadsheet, which contains the metadata for the ATC corresponding to the flatness tolerance from the machined bar CTC.

The test case browser UI I authored with XForms provides access to the 2D presentations of all of the test cases. The browser has three tabs (patterned after the tabbed browsing example in Steven Pemberton's XForms tutorial [11]), each providing a different way to browse the test cases and view their corresponding images. One tab enables users to browse by CTC, drilling down to the ATCs associated with the CTC. Another tab lets users select from a list of all ATCs. The third tab allows users to browse by PMI category. Figure 4 shows a screen shot of the UI. To get to the state shown in the screen shot, the user first selected the machined bar part (Bar with Simple Features) CTC using the Complex Test Cases tab. This interaction caused the UI to generate a list of radio buttons representing each of this CTC's ATCs. Next, the user selected the Feature Control Frame Directed to Surface - Flatness ATC from the auto-generated list of ATCs, resulting in this ATC's PMI category, specification, and measurand appearing at the bottom of the screen. The user then clicked on the View Image button, causing the ATC's 2D image to appear.

Figure 4

Test case browser screen shot.

The test case browser UI's XForms processor is XSLTForms^† [12], which is implemented as an Extensible Stylesheet Language Transformation (XSLT) [13] that runs natively in common Internet browser clients without the need for plugins. I chose XSLTForms both to ensure cross-platform support and to eliminate the need to install any specialized software on the server. Anyone with a typical online desktop computing environment can access the UI. All that is needed is for the browser client to be able to retrieve the files, either from a server or from the local file system.

The source document defining the test case browser UI is an XML document I authored using Leigh Klotz's XHTML+XForms schema [14]. The source document's XForms model element contains static instances extracted from the spreadsheet data shown in Table I and Table II. The source document is approximately 500 lines long, excluding the static instance data, which resides in separate files. The model element also specifies dynamic instances corresponding to each tab in the UI. The dynamic instance data changes as the user interacts with the form. For example, the instance data associated with the Complex Test Cases tab after the user selected the machined bar CTC and the ATC for flatness tolerance as shown in Figure 4 is as follows:

<data> 
  <ctcNumber>1</ctcNumber> 
  <ctcURL>TestCases/CTC/1.pdf</ctcURL>
  <ctcThumbnailURL>TestCases/CTC/thumbnails/1.jpg</ctcThumbnailURL>
  <atcNumber>17</atcNumber>
  <atcFileName>nist_atc_017_asme1_rc</atcFileName>
  <atcURL>TestCases/ATC/PNG/nist_atc_017_asme1_rc.png</atcURL>
  <ctcCount>5</ctcCount> 
  <atcCount>10</atcCount> 
</data>

NIST SP 800-53 Security Control Catalog User Interface

NIST Special Publication 800-53 Revision 4 is a widely-used standard that provides a comprehensive catalog of tailorable security controls for organizations to manage cyber-risk. The controls are organized into eighteen families shown in Table III. SP 800-53 specifies three security control baselines (low, moderate, and high-impact), as well as guidance for customizing the appropriate baseline to meet an organization's specific requirements. In addition to customizing a baseline, an organization or a group of organizations sharing common concerns can create an overlay customizing a set of controls with additional enhancements and supplemental guidance. One overlay recently developed is for Industrial Control Systems (ICS), which are prevalent in the utility, transportation, chemical, pharmaceutical, process, and durable goods manufacturing industries. ICS are increasingly adopting the characteristics of traditional information systems such as Internet connectivity and use of standard communication protocols. As a result, ICS are vulnerable to many of the same security threats that affect traditional information systems, yet ICS have unique needs requiring additional guidance beyond that offered by NIST SP 800-53 [15].

Multiple overlays can be applied simultaneously. For example, a consortium of automobile manufacturers might want to develop their own overlay addressing security concerns specific to their industry. They would then apply both the ICS overlay and the automotive-specific overlay to the NIST SP 800-53 security control baselines.

Figure 5 shows a UML conceptual model of the NIST SP 800-53 security control catalog. A Control has the following attributes:

A Control also contains zero or more ControlEnhancements and SupplementalGuidances. Each of the Control's ControlEnhancements has a baseline-impact attribute specifying whether the enhancement applies to low, moderate, or high-impact systems. Each of the Control's SupplementalGuidances includes zero or more associations to other controls.

Figure 5

Security control conceptual model.

NIST SP 800-53 provides the security control catalog, baselines, and impacts as document appendices. This information totals over 280 pages of text and tables, more than half the page count of the publication as a whole. Figure 6 shows the SP 800-53 definition for the CONTENT OF AUDIT RECORDS control. This control is a member of the Audit and Accountability (AU) family, has a unique ID of AU-3, a priority of P1 (i.e., implementation of this control should be a top priority), a baseline impact of LOW (i.e., this control is included in all three SP 800-53 baselines), and has supplemental guidance specifying associations with three other controls in the AU family and one control in the System and Information Integrity (SI) family.

The CONTENT OF AUDIT RECORDS control definition includes two enhancements: (1) ADDITIONAL AUDIT INFORMATION and (2) CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT. Enhancement 1 has a baseline impact of MODERATE (i.e., additional information is required for audit records of moderate and high-impact systems). Enhancement 2 has a baseline impact of HIGH (i.e., generation of audit records must be centrally managed for high-impact systems), and is associated two other controls in the AU family.

Figure 6

A control as presented in the NIST SP 800-53 document.

As an aid to implementers of NIST SP 800-53, the United States government's National Vulnerability Database (NVD) [16] provides the security control catalog information in an XML format. The following shows a simplified version of the NVD data representing the CONTENT OF AUDIT RECORDS control shown in Figure 6 (with prose text suppressed to shorten the listing).

<control>
  <family>AUDIT AND ACCOUNTABILITY</family><number>AU-3</number>
  <title>CONTENT OF AUDIT RECORDS</title>
  <priority>P1</priority><baseline-impact>LOW</baseline-impact>
   <supplemental-guidance>
    <related>AU-2</related><related>AU-8</related>
    <related>AU-12</related><related>SI-11</related>
  </supplemental-guidance>
  <control-enhancement>
    <number>AU-3 (1)</number><title>ADDITIONAL AUDIT INFORMATION</title>
    <baseline-impact>MODERATE</baseline-impact>
    <supplemental-guidance/>
  </control-enhancement>
  <control-enhancement>
    <number>AU-3 (2)</number>
    <title>CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT</title>
    <baseline-impact>HIGH</baseline-impact>
    <supplemental-guidance>
      <related>AU-6</related><related>AU-7</related>
    </supplemental-guidance>
  </control-enhancement>
</control>

User interfaces for navigating the NIST SP 800-53 security controls already exist. These implementations [17,18] contain hyperlinked web pages generated from the SP 800-53 XML data. However, software support for creating and browsing SP 800-53 overlays does not yet exist. XForms is well-suited for authoring overlays for the following reasons:

A UI for browsing the security controls catalog and creating overlays can be implemented in a manner similar to that of the PMI test case browser, with static model instances corresponding to XML data from the NVD, the information in Table III, the data sorted by priority, and the data sorted by impact. The latter three instances can easily be generated from the first instance using XSLT.

Although a standardized XML vocabulary for representing overlays does not exist, XML's namespace mechanism provides a handy way to augment the NVD's NIST SP 800-53 XML data with overlay information. As an example, let us revisit the CONTENT OF AUDIT RECORDS control (AU-3) shown in Figure 6. The ICS overlay in the draft second revision to NIST SP 800-82 [15] adds additional guidance to this control stating that, if a particular ICS information system lacks the ability to generate and maintain audit records, a separate information system could provide the required auditing capability instead. Now suppose a subset of the ICS community were to create its own sector-specific overlay to be used in addition to the NIST SP 800-82 ICS overlay, and that this sector-specific overlay changes the baseline impact of Enhancement 1 of AU-3 from MODERATE to LOW.

The following XML represents the original AU-3 data augmented with the modifications provided in both the ICS and sector-specific overlays. Each overlay has its own namespace, and the overlay modifications are shown in boldface for readability. XML data not in an overlay namespace is identical to the NVD data for AU-3 shown previously. The ics:supplemental-guidance element contains the additional guidance for AU-3 as specified in the ICS overlay. The s:baseline-impact element contains the change to Enhancement 1's baseline impact as specified in the sector-specific overlay. The s:rationale element contains the rationale (prose text not shown) for increasing the scope of the low-impact baseline to include Enhancement 1.

<control xmlns:ics="http://www.nist.gov/ics-overlay" 
      xmlns:s="http://www.example.com/sector-specific-overlay">
  <family>AUDIT AND ACCOUNTABILITY</family>
  <number>AU-3</number>
  <title>CONTENT OF AUDIT RECORDS</title>
  <priority>P1</priority>
  <baseline-impact>LOW</baseline-impact>
   <supplemental-guidance>...</supplemental-guidance>
  <ics:supplemental-guidance>Example compensating controls include 
providing an auditing capability on a separate information
system.</ics:supplemental-guidance>
    <control-enhancement>
      <number>AU-3 (1)</number>
      <title>ADDITIONAL AUDIT INFORMATION</title>
      <baseline-impact>MODERATE</baseline-impact>
      <s:baseline-impact>LOW</s:baseline-impact>
      <s:rationale>...</s.rationale>
      <supplemental-guidance/>
    </control-enhancement>
    <control-enhancement>...</control-enhancement>
</control>