System Engineering is truly one of the staple buzz words of the ITS movement and becomes even more useful when trying to address and accommodate the various elements of an Integrated Transportation Management System (ITMS). Yet if you were to ask a number of experts (from out-of-town and carrying a briefcase) to define the term you would receive a virtual panoply of answers. So the thrust of this paper is to discuss the basic system engineering methodology with the hope that a clear understanding of the process will lead to a tighter definition of the term. More importantly, I would hope that this clearer understanding will lead to a more widespread utilization of the complete process for while there are a number of "System Engineers" running around the market place, there are very few "Systems Engineers"!!

The complexities of meeting all of the needs, wants, and desires inherent in a mature and robust Integrated Transportation Management System (ITMS) requires a central operating system capable of efficient integration of multiple component systems. Given the potential for fragmentation of focus and dysfunctional design stemming from the "multiples" (agencies, jurisdictions, modes and disciplines) resident in and supported by an ITMS, without a structured approach for development of this core operating system chaos would reign supreme. This structured approach is known as System Engineering.

The term "System Engineering" or "SE" originated in the defense contracting world. These contractors have been exposed to the process in detail since most Government procurements are very stylized and configured to facilitate this process (in fact it is MIL-STD-499B) which reads as follows:

In a basic sense "System Engineering" is the name given to the structured process followed to move an idea from concept to reality. It can be applied equally well to product and process development, to changes, modifications and improvements or to verification processes. Since I believe that one of the major needs of a successful ITMS implementation is for some form of a decision support or management system to serve as the core integrating element, I would suggest that you let the development of one of these systems be the mental backdrop as I lead you through a discussion of the model. Further, since this paper is being addressed as part of an introductory session I will keep it very generic and stylized to aid in building a common reference point for discussions throughout the remainder of the conference.

Basically, system engineering is the process that 1) brings together all of the requisite diverse expertise in a timely manner to accomplish the primary life cycle functions necessary to define, design and verify system elements of products/processes; and 2) effectively directs and controls the totally integrated engineering effort. The core or cornerstone document for this controlled, efficient and integrated growth is a comprehensive front-end study based on a thorough analysis of the real or to-be-implemented management philosophy and those uncontrollable variables such as fiscal constraints, political considerations, environmental impacts, "upstream" requirements, etc. that will impact development of the system. This is where real world considerations shape the development the most. Not to say that changing external conditions won't have an impact later, it's just that they have the biggest push at this stage.

Generally, design of any system's life cycle must address all aspects of planning, acquisition, training, operation and, eventually, tear-down. The length of this life cycle can vary from days to years but still there is a constant requirement to establish the basic operating parameters as early as possible and to identify the interrelationships of the various parts of the total system.

Within this overall system description, each functional/specialty area should be described in as much detail as possible using the same life cycle phases. Its relationship to other sub-systems and to the central controlling node should then be documented. With this baseline system description in hand, it will be far easier to add, modify, or shrink capability to meet future emerging requirements thus facilitating a controlled growth of the basic overall system.

The resultant performance and system specifications establish the baseline upon which to build. Additionally these parameters will provide the basis for trade-off analyses for future acquisition decisions.

How do we get there? Essentially the operating system is described, then a backward planning sequence is applied to delineate the milestones applicable to each individual subsystem as well as those applicable to the system as a whole. This is not to imply "once done, always done" for as new requirements emerge (the Automated Highway System) this system description can be amended to accept and/or accommodate growth and do so in a controlled manner. In essence, the system description provides the guidelines for any future incremental growth. It must be a living document with a preplanned method of accommodating and managing change. A well-planned SE process will facilitate the latest development buzzword—Concurrent Engineering.

With that as background let me address the Waterfall Chart (Fig. 1), the traditional method of depicting the system engineering process. There are fancier models for development, i.e., the Spiral Model, but this is a tried and true package.

Figure 1. The Waterfall

In the beginning—Program Formulation: Here we accomplish the decomposition of the task requirements. Given that a management system exists solely for the conduct of functions supporting a defined requirement and the associated tasks, it is critical to get right down to answering the question—WHAT'S THE JOB? There is a critical need to scope the task requirements—now and future. These will put bounds on the development task and provide the parameters to do prioritization as driven by funding, schedule or one of the uncontrollable variables mentioned earlier. Having developed the program requirements, we can generate the cost and schedule estimates and the programs, plans and procedures strategy. Notice that I have used the words "estimates" and "strategy."

Next there is System Definition. In this stage we do some serious tradeoff and analysis work. We should expect to have identified the institutional requirements (what will be the impacts of the Personnel Merit Board?) and generated a validated schedule (do I have to match the Fiscal Year spending profile to align with Federal dollars?). We also should expect to identify the technical baselines, staffing (technology doesn't necessarily bring smaller staffs) and operating concepts (centralized vs. decentralized), security requirements, demographics, budget projections and, of no small importance, the impact of and on other projects. The products expected from this phase will be a preliminary bid package, conceptual design, life cycle cost and schedule, system and interface specifications and the system test and acceptance plan (you should know now what will make you happy in the future). Pretty ambitious step!! But if you believe in the old parable that a journey of a thousand miles begins with a single step, you will go a long way to achieving final success in a timely and efficient manner if you take the time to do this well!!

It is this area where I have found the greatest variation in levels of completeness as I have talked with various transportation agencies. Let me just offer that being as precise and complete as you can here may more than repay the cost to get there. I say this because the more imprecise the front-end documentation, the less documented the requirement, the higher the risk as seen by any potential system designers. And "Risk" translates to higher bid prices on proposals. In short, if you know what the job entails, can translate it in terms of requirements documents, can put it all together in a conceptual design and have well-defined acceptance criteria, you are on your way to having a very productive and efficient development process.

We are on a roll now as we get to the System Design Phase. We've gotten through the "What's my job and what do I need to do it?" Now we are going to go buy it. But wait! There is a proper way to do that as well. Although it is fun to go ripping through the technologically superior whiz-bang things (non-intrusive VIDS, spread spectrum, mega-power computing, etc.) in the market place and buy one of each. We need to do a bit more on the thinking side before emotion runs rampant. There really are several sub-steps in the process, the first of these being Critical Item Evaluation. Here we resolve the risk issues, look at site considerations and take a good hard look at what is on the horizon technically.

Having done that we can then (and only then) move into Preliminary Design. We ensure that all valid requirements as established in the first step, have been included in the design, that we have approved the long lead items for procurement and that our Staffing and Operating Plans are prepared. The product of this stage is a set of Preliminary Drawings.

This leads to the Final Design where once again we validate that we have not dropped nor exceeded our ability to meet the requirements and we establish a training program. The products of the stage are Construction Drawings and Procurement Packages.

Here's where we hit the light of day—the System Acquisition and Development Phase. If there is a major disconnect with the proper application of the System Engineering process and the real world, it is that construction/development of many of the management systems I've seen have entered the process at this point. A problem or a need exists, somebody has a great piece of technology, money is available, so construction or acquisition begins. Does the word "Topsy" strike a familiar chord? No one takes the time to go through the front-end, almost rote, process steps to validate the decision. With the gleam of high-tech in their eye, they buy something NOW!!!!! Yet if we were to do it right, then this step, which could be called Construction or Acquisition, would not only verify that it was built as designed but that the product was built as designed from a system perspective. It is tough to determine that the requirements were met if we haven't established the requirements. However you get to the point, right or wrong, you would obviously expect to get something from this process—the "As Builts."

Remarkably you would expect that since we have now entered the process that all else would conform to the model. Again, not so fast. System Integration and Test has a great ring to it. Yet it is one of the most over-used, misunderstood terms I know. Just as the Requirements Definition phase sets the standard, SI&T ensures the performance. Actually there are really two steps in this stage—Installation and Integration and Test and Operation.

In the Installation and Integration step we implement a Test and Acceptance Program (the sell-off) and conduct a training program. You should expect to see installation drawings laying out a set of functional and interactive subsystems all of which lead to the fully functional system.

But to prove it works you have to submit the system to some serious down home testing. This is the purpose of the Test and Operation step in the process. Based on an identification of the key subsystems you submit the whole package to a process whereby you sign off each key and critical element by either test, analysis, demonstration or inspection. This is all done in accordance with formal Test Plans and Test Procedures. This is the stage where the independent Quality Assurance process earns its keep. When you are done you have tested the system in almost the reverse direction from the way you built it. In short, you design from the top down and test from the bottom up: you test each piece, you test each piece as a part of a subsystem, you test each subsystem as a part of the whole and you test the whole as an entity to ensure that it meets the requirements you established in the Program Formulation stage. My other plea here is to be sure that the pressure of time does not override the requirement to do a good SI&T.

And then suddenly you are about to hit that magic stage called Deployment. It will be there, it will work and all of your cares will be gone.

You aren't done yet. There's a thing call Life Cycle Support (some would cheapen the phrase by referring to it as "Maintenance"). To be a complete design and a truly integrated system we need to know going in what our life cycle costs and procedures must be. We need to do an analysis of the "Pairs and Spares" and do an interchangeability analysis. Many vendors use similar components but under different part and serial numbers. It would be nice to know that the Flonoteny Rod Mfg.'s part # 2717 used to cleviate kelterpflime is the same as AJAX Supply's part # a-649 that is integral to the operation of the light and sound machine. You need to catalogue and analyze those bits, parts, and pieces that make up your system. You'll need to address not only initial capability training, but sustainment and growth training for your work force. You'll need the "As-built" drawings and Operator Manuals and to establish a set of Logs for each piece of the system requiring a detailed history of operation and maintenance activities.

And yes there is something missing here. Configuration Management (CM). The four basic elements of CM are Configuration Identification, Configuration Change Control, Configuration Status Accounting and configuration Identification. A Configuration Management Plan (CMP) defines the direction and surveillance applied to ensure positive identification, control and status accounting of hardware and software performance requirements and the attendant testing through all of the Life Cycle phases. Effective CM requires efficient integration of many organizational responsibilities but the inherent differences between hardware and software as well as the unique standards and methodologies applicable to the two disciplines require separate approaches be applied. A good CM plan describes the procedures for proposing changes to the configuration baseline, their evaluation and approval and the methodology for implementation following approval.

As a minimum, the Hardware Configuration Master Plan (HCMP) describes the baseline equipment configuration and establishes program control and accounting procedures including: a family tree block diagram of the overall equipment showing all assemblies and major purchase parts, item quantities and parts numbers (as available). The Software Configuration Master Plan (SCMP) provides the required management visibility into the software analysis, design, development, test and operation environment.

Where do you go from here? Given that the half-life of computers is shrinking and that requirements are ever emerging, you have some serious pondering to do. But wait—you have established the process to do so. You have a clear focus on today's requirements and the resulting operational concept; you have implemented an efficient and focused operational design and you have a configuration management process to allow incremental and efficient future upgrades.

I'd love to tell you that it would be a total bed of roses and a piece of cake to design a system but it just isn't so. But using an ordered process makes it far easier and efficient with far less wasted motion and resources. Please understand that the Waterfall Chart isn't the only way to accomplish System Engineering. It is a very simplistic, and possibly misleading, device since it tends to represent a sequential process which is not the case at all. In fact, many of the steps are overlaid and repetitive but this occurs as a function of each situation so it is impossible to show all potential combinations and permutations.

In closing, I would hope that you've gained several teaching points from the foregoing. To work the SE process well:

From the foregoing have intended to lay out a process whereby you can take the overall concept for implementation of an ITMS and turn that into a developmental process for the core system that will serve as the glue. And this is not to say that the process only applies to the core system. It can (and should) be applied to every component system as well—it is only a matter of perspective. What is an external condition for a component system may well be a feature of the core system. It will address development of inter- and intra-system voice, video and data communication, training needs, operational procedures, training needs and budgeting.

It may be difficult to identify that point at which you transition from thinking about operating a system to designing a system. And that's just fine. You don't necessarily want to let technology run rampant. It can support change; it shouldn't necessarily drive it. Other than that all I would tell you is to have a good time using the process. The next time somebody drags a high-tech widget in the door you can nod knowledgeably and consider his offering from a systems context. You can look him in the eye and ask "what's this going to do for me today?"

Good Luck!