Description
Objective: Demonstrate an improved automated tropical cyclone forecasting, analysis, and dissemination tactical decision aid capability that uses a modern containerized software backend/frontend and is able to easily integrate legacy and novel component algorithms, models, databases, and Application Programming Interfaces (APIs). Description: Domestic operational tropical cyclone forecasting at the Joint Typhoon Warning Center (DOW), Fleet Weather Centers (DOW), and National Hurricane Center (NOAA) have relied on the Automated Tropical Cyclone Forecast System (ATCF®) software suite for end-to-end tropical cyclone analysis, forecasting, and product dissemination for over three decades. This one-stop-shop for all data, modeling, post-processing, and user interaction for tropical cyclone information has endured due to its robust assured infrastructure, reliability, speed for executing actions, and long continuity even as forecasters and information have evolved. However, as compute environments and programming languages have changed, it has become more difficult to maintain and upgrade legacy software to take advantage of new capabilities. This STTR topic seeks the development of a prototype software suite that can learn lessons from the success of ATCF®, but is architected in a modern software ecosystem to mitigate current workflow disadvantages. Fundamentally, the goal is a modular and containerized software application that can variously interact with legacy, current, and future software suites such as components of ATCF®, the Naval Integrated Tactical Environmental System Next Generation (NITES-Next) program, the NOAA Advanced Weather Interactive Processing System (AWIPS), and other back-end and front-end APIs. The software architecture must be designed from the outset to comply with DOW DevSecOps principles and prepare the system for the Risk Management Framework (RMF) process. Desired software requirements include design in a modern broadly supported and maintained open programming language that can run online or offline on premises or in a cloud compute environment; hardening against connectivity and bandwidth issues; separation of functionality between logic, database, analysis algorithms, forecast generation , user interface, and dissemination layers; modular component development where different parts can interoperate with other software; and the ability to quickly address software updates and functionality and revert on the client side. A dual-pronged approach to improving workflow for the tropical cyclone forecast process is envisioned, with parallel development tracks for software architecture creation and decision support aid integration. While the focus of tropical cyclone tools in the 1980s through 2000s was on track and intensity prediction, the forecasting mission has increasingly expanded. This includes the ability to track before storms have formed; 3D storm structure and rainfall evolution; ocean and wave field information; storm surge and hazards; probabilistic uncertainty; and emerging machine learning tools. The software should be capable of generating and disseminating an automated, objectively optimal analysis and forecast product from available data — that is, without significant manual human effort. It is not expected that all these efforts are achievable within the scope of this STTR effort; however, the priority development schedule must be justified, and the software solution must be able to accommodate all of these components within a future strategic plan. Back-end capability should include: (1) a modern development software framework that can easily include or remove proprietary and open source algorithms as desired and is built and deployed as a containerized architecture; (2) a robust state management (e.g., database) for storm information and aids with backwards compatibility and export for current ATCF® “deck file” formatting; (3) concurrency for data fetching and processing to reduce data latency for time-critical forecast workflows; and (4) defined APIs to provide data access to clients, such as front-end graphical user interfaces (GUI) or downstream machine-to-machine programs. Further, the back-end capability should support backup capability, likely through a distributed system of servers. Front-end capability should include: (1) thin client(s) for use on desktop workstations and possibly within web browsers, facilitating both on-site and remote operation with both client-side and server-side rendering tested for DOW network responsiveness; (2) flexible means of calling external scripts/functions/APIs with configurable input data, allowing forecasters to trigger different production pipelines and workflows that could be defined externally; (3) editable runtime configuration facilitating separate profiles for different operational systems or users; (4) means to integrate with internal and/or external AI systems or agents to facilitate future workflows; and (5) GUI and storm management capabilities consistent with ATCF®, with additional emphasis on performant map navigation and rendering, multi-product and format overlays (from gridded and sparse data, such as from kml, kmz, ShapeFiles, GeoTiff, HDF, netCDF, GRIB2, Zarr, GeoJSON, etc.), and dynamic filtering and alerts for data as they populate in real time. It is imperative that software developed be done so with an emphasis that support does not require skills beyond those currently required and normally used by support staff at forecast centers. Keywords: Tropical cyclone; typhoon; Automated Tropical Cyclone Forecasting; ATCF; user interface; algorithms; modular; refactor; cloud; database; container; Application Programming Interface; API; graphical user interface; GUI; software CMMC Level: Level 2 (Self)