We apologize for the inconvenience. Please see our site index or use the site search above.
As you have probably noticed, we have recently undergone a new design effort of arm.gov. In the process, many links have been broken and some content not yet migrated. Please let us know what you cannot find.
We apologize for the inconvenience. Please see our site index or use the site search above.
As you have probably noticed, we have recently undergone a new design effort of arm.gov. In the process, many links have been broken and some content not yet migrated. Please let us know what you cannot find.
This document defines the ARM Climate Research Facility (ACRF) engineering processes. Specifically, the Engineering Change Request (ECR), Engineering Change Order (ECO), Engineering Work Request (EWR), and Engineering Work Order (EWO). These processes are used to initiate and manage the ACRF engineering design process.
An engineering change process begins with an initial request (ECR). An approved request is converted to an ECO that provides for requirement analysis, design, development, documentation, training, and testing. The conclusion, upon completion of the ECO, in most cases will result in a revision to the operational ARM baseline (Baseline Change Request or BCR). In addition, as a complement to the ECR/ECO, an EWR/EWO process is defined where "quick-turnaround" tasks can be accommodated as an integrated adjunct to the ECR/ECO, BCR and Problem Identification Form (PIF)/Corrective Action Report (CAR) processes.
Throughout the process, we define roles and responsibilities along with tracking methods to facilitate understanding, priority, impact, and status of tasks. The desired outcome of the ECR/ECO process is to establish a set of foundation methods that allow us to communicate more effectively while developing well-engineered products.
The desired outcome of the EWR/EWO process is to establish a procedure and method that allow us to take prompt action on pressing problems (usually of an operational nature).
Please refer to the Glossary at the end of this document for definitions of terminology.
The ECR/ECO process establishes a method that members of the ACRF Science, Operations, or Engineering components may use to submit requests for new systems, products, or functionality from ACRF Engineering. The concept of "new products or functionality" refers to the idea that requests made to Engineering will ultimately result in changes to the baseline configuration of our data systems, science products, instruments, communications equipment, data products, or physical aspects of a site. Engineering tasks will be "needs-based" and will result from the scientific, operational, or engineering needs of the ACRF.
The ECO process helps set priorities within Engineering to guide the implementation process. The environment of limited resources, in which the Infrastructure operates, requires that a tradeoff is made based on the importance, impact, and cost of the ECO. The ECO approval and review process helps ensure this analysis takes place. Thus, over the long-term, this process enables us to do more science in terms of products, sites, and field campaigns.
Figure 1 outlines the proposed ECR/ECO process. Each "block" in the flowchart is numbered and a description of each block follows.
A request for engineering tasks in terms of an ECR is initiated by the ACRF Science, Operations, or Engineering components. An ECR is initiated in the following ways:
An ECR describes a request for an engineering task that requires attention to requirement definition, analysis, design, documentation, testing, and delivery.
Tasks results from requirements generated by the ARM Science Steering Committees (SSC). Examples of possible requests include new value-added products, the addition of new instruments to address unmet measurement needs, or a new site, are examples of possible requests. If an ARM scientist has a need for an engineering request, it should be discussed within the respective Science Steering Group until a consensus is reached, approved by the Chief Scientist, and submitted by the "Translator" (see paragraph 2.2.1) as an ECR. Each SSC will have a dedicated Translator.
Within Operations, anyone can be a Representative and submit the ECR. Tasks can resolve problems, enhance the functionality of our systems, or revise the physical infrastructure.
Within Engineering, anyone can be a Representative and submit the ECR. Tasks can resolve problems, enhance the functionality of our systems, or revise the physical infrastructure.
Translate a specific science request or represent an Operations or Engineering need into a request for engineering resources (the ECR). Nominally, some discussion needs to take place between the Translator and the respective constituents before the request is submitted as an ECR. This ensures the request is well defined and understood.
A Science Translator is a Science Steering Group representative that is responsible for defining and filing an ECR. This person is a member of the Infrastructure and is the point of contact for ECR/ECO status and clarification.
The Operations representative is responsible for defining and filing an ECR. This person is a member of the Infrastructure and is the point of contact for ECR/ECO status and clarification.
The Engineering representative is responsible for defining and filing an ECR. This person is a member of the Infrastructure and is the point of contact for ECR/ECO status and clarification.
The Translator or Representative will use the ECR tool (http://ecr.arm.gov) to enter the following information:
Upon submission, the ECR will be indexed, logged, and routed to the ECR Manager, Engineering Manager, and Chief Engineer.
Please not that this tool is an adaptation of the existing BCR system, thus maintaining the same look, feel, and dialog process.
The ECR review team, assigned by the Engineering Manager and Chief Engineer, will route the ECR to engineers with the domain expertise to assess the impact and content of the request.
Feedback to the Translator or Representative is required when disposition is reached. Final disposition of the ECR is made by the Engineering Manager, Chief Engineer, and Technical Director and is based on a review of the ECR content. An approved ECR is closed and is routed to the ECO review team. A rejected ECR is simply closed.
The Engineering Review Board (ERB) consists of the ACRF Coordination Team, and Chief Engineer. This review board gives final approval of an ECR and a priority is assigned. The ECR is considered in the overall context of the program during the assignment of priority, so that the programmatic impact of performing the ECR is understood and communicated. The approval, cancellation, or rejection of an ECR is communicated to the Translator or Representative.
The ECO is indexed, logged, and assigned. In this phase, the following steps as detailed in the relevant Project Guides Plans must be added to document the ECO:
The ECO will be logged into the Engineering Tracking Tool upon approval and assignment.
The ECO leader and team will begin work on the task (or place the task in queue). Each ECO will be tracked with periodic updates generated to the Translator or Representative. The ACRF Infrastructure Management Board (IMB) will also review a summary report of engineering tasks to ensure that the right balance or tasks are ongoing. Resources within Engineering will be reassigned as needed to support scientific and operational priorities.
The flowchart shown in Figure 2 outlines a process for "quick turnaround" engineering tasks. Where the ECR/ECO process is intended to manage more complex engineering requests, the EWR/EWO is intended to address engineering work where design (or redesign) is minimal (or not required at all). Upon analysis of an EWR/EWO, it may be determined that an ECR/ECO is required to resolve the task. In that case, the respective EWO is closed and an ECR initiated. Each "block" in the flowchart is numbered and a description of each block follows.
A request for engineering tasking in terms of an EWR is identified by an Operations, Science, or Engineering component.
PIFs, when assigned by the PRB, can directly initiate an EWR by assignment to ewr@arm.gov.
Discussions related to the PIF can result in its resolution before it is submitted for action. If action is required, then the problem context needs to be presented.
The requesting party describes the problem submitting an EWR by (1) using the Engineering Task Tracking Tool (preferred), (2) describing the request via text in an email to ewr@arm.gov, or (3) phoning an Engineering Consultant. A priority determination for the task is required. This clarifies dialog between blocks 3.0 and 4.0 in Figure 2. There will be a minimum of three Engineering Consultants identified to receive the ewr@arm.gov communications. Their job is to focus incoming EWRs toward assignment resolution.
An EWR should be initiated when Operational, Scientific, or Engineering needs require a quick engineering response where no design or redesign is required.
Upon discussion and review of the problem, an Engineering Administrator will log an EWR and notify the requester of the status.
The EWR is closed and the EWO is indexed, logged, and assigned. The following information needs to be added to document the EWO at this time:
The EWO will be logged into the Engineering Tracking Tool.
Evaluate the problem and define the resolution.
The Engineer closes the EWO by communicating the resolution to Operations, filing a BCR, filing a PIF or CAR, or by filing an ECR.
The Engineering Task Tracking Tool (ExtraView) provides the necessary tools for management of the ECO and EWO. Metadata related to associated ECRs and EWRs are recorded within the respective "Orders" task entry. This tool is used by Engineering to perform resource loading and to track and communicate status. The audience is internal, and in addition to managing the engineering process summary, extractions of information are used by the ACRF IMB to facilitate resource conflicts, scheduling, and set priorities.
ARM Climate Research Facility (ACRF) - Formerly the ARM Program Infrastructure.
Baseline Change Request (BCR) - A BCR is a Web-based tool used to discuss, review, and approve an "engineered product" (from an ECO) as it is turned over to Operations. See Baseline Change Request Guidelines for more details.
Chief Engineer - Reports to the Engineering Manager and is responsible for approval and oversight of all ACRF engineering projects.
Corrective Action Report (CAR) - See PIF.
Data Quality Report (DQR) - See PIF.
ECR Review Team (ERT) - The ECR review team, assigned by the Engineering Manager and Chief Engineer and routes the ECR to engineers with the domain expertise to assess the impact and content of the request. This would be a first discussion of scope, schedule, and resources of an ECR.
Engineering Change Order (ECO) - An ECO is simply an engineering task or project directly resulting from an ECR. It addresses project requirements, analysis, design, development, testing, and documentation. In most cases, every ECO is completed by issuance of a BCR (and/or CAR if required) as managed by the Engineering and Operations Managers.
Engineering Change Request (ECR) - An ECR is a request to perform engineering entered into a Web-based ECR too, where discussion and approval (or rejection) is granted. An approved BCR triggers an ECO.
Engineering Consultant - A member of the ACRF Engineering group who serves as a consistent point of contact for Operations.
Engineering Manager - Member of the IMB and is responsible for Engineering within the ARM Program.
Engineering Options Considerations - Checklist used to communicate information related to design options/considerations to peers, Engineering Manager, Chief Engineer, or Instrument Coordinator.
Engineering Review Board (ERB) - The ERB consist of the Archive, Engineering, and Operations Managers, and Chief Engineer. The board gives final approval of an ECR, where it becomes an ECO, and assigns a priority.
Engineering Work Order (EWO) - An assignment of tasking to Engineering to resolve an EWR.
Engineering Work Request (EWR) - An EWR (email contact to ewr@arm.gov) is used to request engineering resources, as soon as possible, when Operational, Science, or Engineering needs require a quick engineering response where no design or redesign is required.
Infrastructure Management Board (IMB) - The IMB manages and coordinates the technical planning objectives of the ACRF.
Intensive Operational Period (IOP) - IOPs are periodically conducted on location at our operational sites to facilitate scientific understanding of posed hypothesis. Often referred to as "campaign mode" activities, duration is defined. They usually involve additional instrumentation, aircraft, satellites, ships, or revisions to the temporal/spatial sampling measurements. For more information, see the ACRF IOPs and Field Campaigns Web page located at http://www.db.arm.gov/cgi-bin/IOP/iops.pl.
Problem Identification Form (PIF), Corrective Action Report (CAR), Data Quality Report (DQR) - Used to identify and document problems with ARM systems, physical infrastructure, or instruments. See PIF/CAR/DQR Frequently Asked Questions for a more in-depth definition.
Readiness Reviews (RR) - Checklists and processes used by site Operations to ensure all necessary physical infrastructure requirements are being met during a design process.
Representative - An Operations or Engineering staff person who proposes an ECR. The representative usually works with management and peers to communicate the need.
Science Steering Committee (SSC) - A Science Working Group that is responsible for a specific area of atmospheric sciences research. The SSC couples the infrastructure closely to the ARM Science Team through the respective SSC translator.
Tracking Tool - A web-based, "commercial off-the-shelf" project development and tracking software package (ExtraView). This tool is used in Engineering and is available across the ACRF for project and task definition, status reporting, and tracking.
Translator - A Science Steering Group Representative that is responsible for defining and filing an ECR for a new, or modification to an existing, value-added product, or instrument system.
For more information, please see Frequently Asked Questions (PDF, 173K).
We apologize for the inconvenience. Please see our site index or use the site search above.
As you have probably noticed, we have recently undergone a new design effort of arm.gov. In the process, many links have been broken and some content not yet migrated. Please let us know what you cannot find.
