Craig Schlenoff
National Institute of Standards and Technology
Bldg 220 Rm A127
Gaithersburg, MD 20899
Tele: 301-975-6536
Fax: 301-258-9749
schlenof@cme.nist.gov
Amy Knutilla
National Institute of Standards and Technology
Bldg 220 Rm A127
Gaithersburg, MD 20899
Tele: 301-975-3514
Fax: 301-258-9749
knutilla@cme.nist.gov
Steven Ray
National Institute of Standards and Technology
Bldg 220 Rm A127
Gaithersburg, MD 20899
Tele: 301-975-3524
Fax: 301-258-9749
ray@nist.gov
Abstract:
The goal of the NIST Process Specification Language (PSL) project is to investigate and arrive at a common, unifying model of process which will ultimately be suitable for multiple process-related applications, yet powerful and robust enough to meet each set of requirements. This paper focuses on the second phase of the project, that of analyzing existing process representations to determine how well they represent the information requirements found in an earlier phase of the project.1.0 Introduction
With so many existing process representations available, how can one be sure that they are using the best one for their purposes? What is the best way to analyze these representations to determine their strengths and weaknesses? If there is not one ideal representation, can aspects of many be merged together? These are some of the questions that are facing the National Institute of Standards and Technology's (NIST) Process Specification Language (PSL) project as we try to determine fundamental foundation on which to base a Unified Process Specification Language.1.1 The Process Specification Language Project
The goal of this PSL project is to identify or create a process specification language (PSL) that can be: 1) common to all manufacturing applications; 2) generic enough to be decoupled from any given application; and 3) robust enough to be able to represent the necessary process information for any given application. Additionally, the PSL should be sufficiently well-defined to ensure complete and correct exchange of process information among established applications. This should not imply that the PSL itself is sufficient for interoperability (undoubtedly there will be a need for translators as well as some sort of formal vocabulary (ontology)), but it is necessary. This PSL would facilitate communication between the various applications because they would all "speak the same language", either as their "native" language or a "second" language, for exchange.1.2 Technical Approach
The approach taken for the project has been to break it into distinct phases, namely: requirements gathering, existing process representation analysis, schema definition, language grammar/syntax development, language notation(s) development, pilot implementation and validation, and finally, submission as a candidate standard. The first phase, requirements gathering, has been completed and documented [24]. The second phase, the representation analysis, is designed to determine how well existing representations support the requirements found in phase 1. This analysis will provide an objective basis on which to identify the representation or combination of representations that provides the best coverage of the requirements and to identify gaps in existing representations' abilities to address process specification requirements. The language schema, grammar, syntax, and notation will be developed as a result of this analysis. By this time, a suitable scenario or group of scenarios will have been identified for a prototype implementation to ensure the completeness and ease-of-use of the specification language. It is this validated, documented language that will be submitted to appropriate organizations as a candidate standard. Feedback and consensus from the process community will be and has been aggressively pursued during all phases of the project.
2.0 Requirements for Specifying Process
The goal of the first phase of the PSL project was to gather the information requirements necessary to represent manufacturing processes. These information requirements can be viewed as providing a context in which to analyze existing process representations.
The area of process representation is a complicated area which can only be understood from looking at the process requirements from multiple perspectives. For that reason, we understand that there are many of ways of categorizing the process requirements. A future paper will be published that confronts this issue. Although this categorization is intended to be implementation-independent (it is not dependent on how the final specification is used), inevitably assumptions about implementation come into play when deciding where each requirement falls. For this reason, many of these requirements can be thought of as categorized differently depending on the reader's perspective.
The first phase of the analysis was to determine how well the representations under study met the requirements. This indeed is an overwhelming task considering that one must have a deep understanding of the various representations in order to confidently say what each can represent. It would take an undesirably long amount of time for any one small group to do this. What is more desirable is to leverage the existing work and expertise.
To make maximum use of existing expertise, a web-based online matrix was created to provide a mechanism for people from all over the world to help with our analysis. This part of the analysis is performed strictly empirically, that is to say, the rating decisions are solely based on the experiments, observations, and experience of those doing the analysis. The framework and context will be provided by the project, but the actual decision and rationale is left solely up to the experience of the reviewer.
Another approach being pursued is the use of a set of scenarios to convey what is meant by each of the process requirements as well as show the relationships between the requirements. In this context, a scenario is a real-world textual description of a set of activities incorporating the information requirements found in the first phase of the PSL project. One would be able to model that scenario in their representation to see exactly where the short-comings of that representation fall. They would also be able to see what requirements the representation is able to easily represent and which requirements require some tweaking in order to capture.
One of the challenges of this approach is creating appropriate scenarios. The scenarios must be created so that they are unbiased to any given representation yet complete enough to clearly convey the requirements to be represented. If either of these characteristics are missing, the results will be skewed and unreliable. Because of the time commitment necessary to create appropriate scenarios, this technique will only be used for descriptive purposes once the final representation is determined and will not be used to perform the analysis.
The second phase of the analysis involves using the matrix to determine what "types" of representations are good at representing what "types" of requirements. This "analysis of the analysis" is performed by first classifying each of the representations under study. This involves associating with each representation a group of agreed upon characteristics that help to describe the representation. Some types of characteristics being considered are:
In additional to classifying the representations, there have also been attempts to categorize the requirements. The reader is referred to [4], [23], and [24] for more information about these categories.
Once the representations are classified and the requirements are categorized, one may look at the matrix to determine what types of representations are good at representing what types of requirements. It is expected, for example, that hierarchical types of representations would be good for handling abstraction. But these discoveries are only the first step. We need to know more than `what', we also need to know `how'. An in-depth look at each of the promising representations will hopefully provide some insight into what constructs are used to capture the requirements.
With the first part of the analysis coming to a close (analyzing the representations on how well they represent each requirement individually), and the matrix of representations vs. requirements just about complete, the next step is to review the matrix to determine "what types of representations are good for representing what types of requirements". Similar to the first phase, this will be performed in conjuction with other experts in the field who have an interest in process representation through the use of a Roundtable discussion scheduled for the end of April, 1997. The goal of this Roundtable is threefold: 1) determine what representations are good for representing what requirements; 2) determine if these representations' aspects can be melded together to form a new representation that is ideal for a Unified Process Specification Language; and 3) come to consensus about what is the appropriate representation for a Unified Process Specification Language. The proceedings of the Roundtable will be published at a later date.
As an alternate approach, preliminary thought has been given to using an ontological evaluation to analyze these representations. To this point, the prospective use of ontologies has been limited to the precise and formal definition of terminology within the specification language. These formal definitions would be needed to ensure correct exchange of information between heterogeneous applications since these applications usually use different terms to represent the same concept. A similar concept could be used to analyze process representations. If a concise and unambiguous definitions of process requirements were given, a representation could be carefully analyzed to determine what aspects of that definition the representation could capture.
For example, if the requirement `concurrent task' was defined (in a formal manner) as two or more tasks that occurred at the same time, with the same start point, the same end point, and the same duration (also assuming start point, end point, and duration were formally defined), then a representation could be analyzed to determine if ALL parts of that definition were captured. Only if all parts were captured would the representation be able to say that it could `completely' represent that requirement.
The ultimate goal of the NIST PSL project is to investigate and arrive at a common, unifying model of process which will ultimately be suitable for multiple process-related applications, yet powerful and robust enough to meet each set of requirements. Once the representation analysis phase of the project is completed and a suitable process representation is determined, we will proceed to the subsequent phases, namely: schema definition, language grammar/syntax development, language notation(s) development, pilot implementation and validation, and finally, submission as a candidate standard.
Ballard, Carl W. "Basics of Behavior Diagrams," Ascent Logic Corporation, Vienna, VA, 1989.
Chen, Peter P (ed). Entity-Relationship Approach to Information Modeling and Analysis -- Proceedings of the Second International Conference on Entity-Relationship Approach, Washington, D.C., October 12 - 14, 1981. North-Holland Publishers, Amsterdam & New York City, 1981.
Duffey, M. "Managing the Product Realization Process: A Model for Aggregate Cost and Time-to-Market Evaluation," with J.R. Dixon, Concurrent Engineering: Research and Applications, London, UK no. 1, vol. 1, 1993.
Grady, Jeffrey O. System Requirements Analysis. New York: McGraw-Hill, 1993.
Gruninger M., Schlenoff C., Knutilla A., Ray, S., Using Process Requirements as the Basis for the Creation and Evaluation of Process Ontologies for Enterprise Modeling (to appear in the ACM SIGOIS Bulletin Special Issue on Enterprise Modelling), August, 1997.
Integration Definition for Function Modeling (IDEF0), Draft Federal Information Processing Standards Publication 183, December 1993.
ISO, Product data representation and exchange: Part 49: Integrated generic resources: Process structure and properties, ISO Standard 10303-49, 1995.
ISO, Product data representation and exchange: Part 213: Application Protocol: Numerical Control process plans for machined parts, ISO Standard 10303-213, 1995.
J. vanderBrug and J. Minker, "State Space, Problem-Reduction, and Theorem-Proving --- Some Relationships," CACM19(2), 107-115 (1975)
Kendall, S., Control of Parts (Parts Making in the Building Industry), PhD Dissertation, Massachusetts Institute of Technology, 1990.
Kiritsis, D., et. al., "Multi-level Petri Nets and Multi-Agent Techniques for Integrated Dynamic Modeling for Process & Job Shop Production Planning," Proceedings of the AIM Workshop, Daimler-Benz, Berlin, September 26-27, 1996.
Kutluhan Erol, James Hendler, Dana S. Nau, Semantics for Hierarchical Task Network Planning. Technical Reports. Computer Science Dept., ISR, UMIACS. University of Maryland, College Park.
Mayer, R., et. al., IDEF3 Process Description Capture Method Report, Technical Report AL-TR-1992-0057 for Armstrong Laboratory Contract No. F33615-90-C-0012, May 1992.
Michael R. Genesereth et al. Knowledge Interchange Format Version 3.0 -- Reference Manual, Computer Science Dept., Stanford University, 1992.
Pease, R. A., Carrico, T. M., JTF ATD - Object Model Working Group, Core Plan Representation (Request for Comment) Draft.
Proceedings of the Sixth International Workshop on Petri Nets and Performance Models, Sponsored by the Center for Advanced Computing and Communication, IEEE Computer Society Press, Durham, NC October 3-6, 1996.
Process Flow Representation (PFR), http://www-mtl.mit.edu/CIDM/SemiAnnual/02.PFR.html, February 27, 1997.
Quirk Model, http://faith.swan.ac.uk/~eegoodw/quirk.html, February 27, 1997.
Ray, S.R., "Using the ALPS Process Plan Model," Proceedings of the ASME Manufacturing International Conference, Dallas, TX, 1992.
Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William; Object-oriented modeling and design, Prentice Hall, 1991.
Schlenoff C., Knutilla A., Ray S., Requirements for Modeling Manufacturing Process. Proceedings of Intelligent Systems: A Semiotics Perspective Conference, Gaithersburg, MD October, 1996.
Schlenoff C., Knutilla A., Ray S., Requirements for Modeling Manufacturing Process: A New Perspective (submitted to the 1997 CIE conference, Sacramento CA) September 1997.
Schlenoff C., Knutilla A., Ray S., Unified Process Specification Language: Requirements for Modeling Process, NISTIR 5910, National Institute of Standards and Technology, Gaithersburg, MD (1996).
Schneider, G. Michael, Bruell, Steven C., Concepts in Data Structures & Software Development, West Publishing Company, 1992.
Smith, S.F. and M. Becker, "An Ontology for Constructing Scheduling Systems", to appear in Working Notes of 1997 AAAI Symposium on Ontological Engineering, Stanford, CA, March, 1997 (AAAI Press).
Tate, A., Representing Plans as a Set of Constraints - the <I-N-OVA> Model, Proceedings of the Third International Conference on Artificial Intelligence Planning Systems (AIPS-96), Edinburgh, May 1996.
The ACT Language, http://www.ai.sri.com/%7ewilkins/tucson/node7.html, February 27, 1997.
The PIF Process Interchange Format and Framework, Jintae Lee et al, http://soa.cba.hawaii.edu/pif/, May 24, 1996.
Visual Process Modeling Language, http://www.issi.com/proslcse-3.5i/vpml.html February 27, 1997.