PS-PVR BACKGROUND
Elizabeth Kline
Randall Race
GOES-R Product Readiness and
Operations (PRO) Team
GLM Science Meeting
September 11-13
, 2018
GOES-R Series
PRO TEAM
Update
PS-PVR BACKGROUND
2
Product Maturity Levels
What do the Product Maturity Levels mean?
There is a Peer Stakeholder Product Validation Review (PS-PVR) at
each stage as a method of informing the user community of the
following readiness for use:
•
Beta
: Products are made available to users to gain familiarity with data formats and
parameters. It has been minimally validated and may still contain significant errors
and is not optimized for operational use.
•
Provisional
: Product ready for operational use but has documented known issues.
Product analyses are sufficient to communicate product performance to users
relative to expectations.
•
Full
: Product is operational. All known product anomalies are resolved and/or
documented and shared with the user community.
GOES-16 Validation Schedule
4
GOES-17 Validation Schedule
5
By 2019, GOES-16 GLM will be Fully validated &
GOES-17 GLM will be Provisional!
6
ALGORITHM CHANGE PROCESS (ACP)
7
8
•
Detect/Identify discrepancy (Algorithm Issue)
in operational data product
•
Report issue for communication with Project
and Team
•
Prioritize within Discipline’s tasks after
evaluation if within scope and resources
•
Investigate cause
•
Resolve the issue in the code, deliver
change package, test, and approve the
change to the baseline
•
Implement the solution in the operational
system
•
Verify solution implemented correctly in
operational system
ACP
9
•
The ACP is facilitated by the Algorithm Action Review Team
(AART) and the Algorithm Review Board (ARB).
•
The AART is a working group that acts on behalf of the ARB to
adjudicate Algorithm Discrepancy Reports (ADRs).
•
The ARB manages the science configuration of the Operational
System. It approves ADRs for implementation.
•
The ARB is responsible for managing the science content of the
GS.
•
The ARB approves ADRs that make changes to the science but not
bug fixes. If a bug fix is needed, a WR can be written without ARB
approval.
Types of Changes
10
•
Non-Science Changes – Changes that do not affect the science
algorithms. These go straight to the WR/DCRB process.
•
Look-up Tables (LUTs) – an array that replaces runtime
computation with a simpler array indexing operation. This is used
to save processing time when the values are known within
sufficient precision.
•
Simple Code Changes – Any code change that does not affect to
I/O, is under 200 lines of code, and is Product Generation only.
•
Complex Code Changes – Any code change that does not meet
the simple criteria.
Types of Software Releases
11
•
The GS contractor, Harris, delivers code updates to the Data
Operations (DO) baseline in the format of a Build, a Patch, or an
Emergency Patch.
•
The naming convention is DO.BB.PP.EP, where
–
BB = build number, e.g. 07
–
PP = patch number, e.g. 00 or 01
–
EP = emergency patch number, e.g. 00 or 01
•
The next major build is DO.07.00.00, due to transition to the
Operational Environment on 10/09/18.
•
The PRO PASS team also releases code updates with a similar
naming convention, but with the prefix PR.
–
For example, the next update that PRO PASS will deploy after DO.07.00.00
will be called PR.07.00.00.
Now onto the fun stuff with Randy Race!
For questions or general information, please contact:
Elizabeth.Kline@noaa.gov or Randall.Race@noaa.gov
12
Peer Stakeholder Product Validation Review (PS-PVR) informs users about product readiness at different stages: Beta stage for familiarity, Provisional stage for operational readiness with known issues, and Full stage for resolved anomalies. The Algorithm Change Process (ACP) involves detecting and resolving Algorithm Issues in operational data products, facilitated by the Algorithm Action Review Team (AART) and Algorithm Review Board (ARB) for managing science configuration and approving changes. Non-Science Changes may also be implemented. By 2019, GOES-16 GLM will be fully validated while GOES-17 GLM will be Provisional.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Product Maturity Levels What do the Product Maturity Levels mean? There is a Peer Stakeholder Product Validation Review (PS-PVR) at each stage as a method of informing the user community of the following readiness for use: Beta: Products are made available to users to gain familiarity with data formats and parameters. It has been minimally validated and may still contain significant errors and is not optimized for operational use. Provisional: Product ready for operational use but has documented known issues. Product analyses are sufficient to communicate product performance to users relative to expectations. Full: Product is operational. All known product anomalies are resolved and/or documented and shared with the user community.
By 2019, GOES-16 GLM will be Fully validated & GOES-17 GLM will be Provisional! 6
Detect Detect/Identify discrepancy (Algorithm Issue) in operational data product Report Report issue for communication with Project and Team Verify Prioritize within Discipline s tasks after evaluation if within scope and resources Investigate cause Resolve the issue in the code, deliver change package, test, and approve the change to the baseline Prioritize Implement the solution in the operational system Implement Verify solution implemented correctly in operational system Investigate Resolve 8
ACP The ACP is facilitated by the Algorithm Action Review Team (AART) and the Algorithm Review Board (ARB). The AART is a working group that acts on behalf of the ARB to adjudicate Algorithm Discrepancy Reports (ADRs). The ARB manages the science configuration of the Operational System. It approves ADRs for implementation. The ARB is responsible for managing the science content of the GS. The ARB approves ADRs that make changes to the science but not bug fixes. If a bug fix is needed, a WR can be written without ARB approval. 9
Types of Changes Non-Science Changes Changes that do not affect the science algorithms. These go straight to the WR/DCRB process. Look-up Tables (LUTs) an array that replaces runtime computation with a simpler array indexing operation. This is used to save processing time when the values are known within sufficient precision. Simple Code Changes Any code change that does not affect to I/O, is under 200 lines of code, and is Product Generation only. Complex Code Changes Any code change that does not meet the simple criteria. 10
Types of Software Releases The GS contractor, Harris, delivers code updates to the Data Operations (DO) baseline in the format of a Build, a Patch, or an Emergency Patch. The naming convention is DO.BB.PP.EP, where BB = build number, e.g. 07 PP = patch number, e.g. 00 or 01 EP = emergency patch number, e.g. 00 or 01 The next major build is DO.07.00.00, due to transition to the Operational Environment on 10/09/18. The PRO PASS team also releases code updates with a similar naming convention, but with the prefix PR. For example, the next update that PRO PASS will deploy after DO.07.00.00 will be called PR.07.00.00. 11
Now onto the fun stuff with Randy Race! For questions or general information, please contact: Elizabeth.Kline@noaa.gov or Randall.Race@noaa.gov 12
