Design of a Standards-Based Cloud Platform to Enhance the Practicality of Agrometeorological Countermeasures

Abstract

The need for systems that forecast and respond proactively to meteorological disasters is growing amid climate variability. Although the early warning system in South Korea includes countermeasure information, it remains limited in terms of data recency, granularity, and regional adaptability. Additionally, its closed architecture hinders interoperability with external systems. This study aims to redesign the countermeasure function as an independent cloud-based platform grounded in the common standard terminology framework in South Korea. A multi-dimensional data model was developed using attributes such as crop type, cultivation characteristics, growth stage, disaster type, and risk level. The platform incorporates user-specific customization features and history tracking capabilities, and it is structured using a microservices architecture to ensure modularity and scalability. The proposed system enables real-time management and dissemination of localized countermeasure suggestions tailored to various user types, including central and local governments and farmers. This study offers a practical model for enhancing the precision and applicability of agrometeorological response information. It is expected to serve as a scalable reference platform for future integration with external agricultural information systems.

1. Introduction

Climate change has intensified the frequency and severity of agrometeorological disasters (e.g., cold damage and drought), threatening agricultural productivity and food security [1,2]. This issue highlights the urgent need for information-based systems capable of forecasting and responding proactively to such risks [3,4]. Major international organizations, such as the FAO and WHO, present risk-reducing strategies based on digital and climate-adaptive agriculture technology, including the Sendai Framework (2015–2030) of UNDRR [5,6,7]. Building on this, various countries have implemented agrometeorological early warning systems that integrate weather forecasts, crop growth models, and crop damage indices, among other factors.

Climate change often affects a wide area, but its impact is particularly pronounced on the local scale, such as in fields, rice paddies, and orchards. Accordingly, the importance of providing fine-scale agrometeorological disaster forecasts that reflect farm-level characteristics, such as microclimate, crop type, and growth stage, is increasingly being emphasized. To respond effectively at the farm level, precise information based on location-based attributes must be provided as a prerequisite to help mitigate disasters [8]. In response to this need, an agrometeorological disaster early warning system (AgEWS) has been developed in South Korea to address these needs [8,9]. It offers detailed farm-specific weather information and countermeasure suggestions in advance [10,11].

However, the current countermeasure suggestions within AgEWS in South Korea exhibit significant shortcomings in management and delivery. The existing data structure for countermeasures was overly simplistic, relying exclusively on two classification axes: crop type and agrometeorological disaster category. Thus, it lacks the granularity to address detailed conditions such as cultivation environments, cultivar differences, and varying risk levels. Moreover, the uniform suggestions from the central government fail to adequately reflect regional agricultural practices and environmental characteristics, severely limiting their practical applicability in the field. Furthermore, terminology and data formats within the system do not comply with public standards or interoperability requirements, resulting in high dependencies between data modules and inefficient data integration processes. Such structural limitations complicate regular updates and external data integration, critically restricting the scalability and effectiveness of countermeasure-related technologies. Decoupling countermeasures from AgEWS enables dynamic, granular updates without disrupting core forecasting functions, thereby addressing scalability and interoperability bottlenecks.

In response to the limitations observed in the current AgEWS system, particularly its insufficient capacity to deliver farm-level, up-to-date countermeasure information, this study explores how countermeasure-related functionality can be redesigned as an independent service. Rather than operating as a subcomponent of AgEWS, the countermeasure function is reconceptualized as a standalone platform that prioritizes fine-grained, actionable guidance tailored to local agricultural contexts. To this end, this paper presents the Agrometeorological Disaster Countermeasure Platform (AgCP), an independent platform designed to support localized decision making for farmers and regional governments. The system is structured through the development of four core standard models: the Countermeasure Data Standard Model, the Countermeasure Management Function Standard Model, the Disaster Countermeasure Service Linkage Standard Model, and a Cloud-based Microservices Architecture Model.

AgCP designed through this research will serve as a decision-making tool for farmers to respond promptly to meteorological disasters and as an advisory manual for rural agricultural guidance services at the government level. Additionally, the proposed system will enhance practical usability on site by integrating organically with various public and private agricultural management platforms, ensuring more detailed and farm-specific guidelines aligned with local crop conditions and cultivation environments. Ultimately, this integrated approach is expected to significantly mitigate agrometeorological disaster impacts and reinforce adaptive capacities and resilience to climate change.

2. Current Status and Limitations of Existing AgEWS Countermeasure Suggestions in South Korea

2.1. Current Status

The existing AgEWS in South Korea is designed to precisely predict weather risks at the farm level and provide farmers with guidelines to support their decision making [8,9]. This section briefly describes the data processing procedure for generating early warnings and countermeasure suggestions.

2.1.1. Production of AgEWS Data

The production process of AgEWS data involves three stages (Figure 1) [12]. First, short- and mid-term forecasts, observational data, satellite, radar, and topographic information from the Korea Meteorological Administration (KMA) are collected and converted into standardized grid data. Second, downscaled meteorological data at approximately 30 m resolution are generated using the topo-climatology model [13,14], which serves as the basis for growth stage estimation and risk analysis. Third, crop growth stages are estimated by calculating growing degree days (GDD) based on crop-specific base temperatures. Subsequently, risk levels classified as Normal–Advisory–Warning are computed considering sensitivities to various disasters such as freezing injury, cold and heat damage [15]. The final outputs are stored as grid-based meteorological disaster prediction and observational data.

2.1.2. Countermeasure Data Construction

The countermeasure suggestions provided by AgEWS are constructed based on agricultural literature and classified according to crop growth stage and agrometeorological disaster type. Countermeasures are categorized into preparedness, response, and recovery according to the response timing. The data structure includes attributes such as crop, growth stage, meteorological disaster, countermeasure type, and detailed guidelines, enabling specific queries based on attribute combinations (

Table 1. Conceptual data structure of AgEWS countermeasure suggestions.

Crop	Growth Stage	Disaster	Countermeasure Type	Content
Green onion	Transplanting	Drought	Preparedness	Prevent water evaporation using plastic mulching
Green onion	Transplanting	Waterlogging stress	Preparedness	Plant in well-drained soils due to high susceptibility to waterlogging
Onion	Wintering	Freezing injury	Recovery	Cover damaged plants with soil to fully bury roots
Onion	Bulb Enlargement	Drought	Preparedness	Irrigate adequately (30–40 mm every 7–10 days around bulb enlargement stage)

).

2.1.3. Generation of Farm-Level Early Warning and Countermeasure Data

Grid-based data generated through the early warning data production process are combined with countermeasure data to produce farm-level data. The farm-specific attributes, including weather, growth stage, disaster type, and risk level, are extracted based on the farm PNU (Parcel Number Unit) code and crop type [12]. These attributes are then matched with corresponding countermeasure data. Ultimately, farm-level early warning data with weather information and associated countermeasure data are generated daily, incorporating farm-specific location and crop information.

2.1.4. Delivery Methods of AgEWS and Countermeasure Information

Daily farm-level AgEWS and countermeasure information is delivered to farmers and regional stakeholders via SMS and web services (https://agmet.kr/ (accessed on 15 July 2025). Text messages are automatically generated for each farm by linking farm-level data through a notification system. They are operational as regular notifications (providing farm-level weather forecasts once a week) and occasional notifications (disaster predictions sent one day prior, including countermeasure suggestions).

2.2. Limitations

2.2.1. Lack of Updates in Countermeasure Data

The existing countermeasure data have been developed based on agricultural technology literature, resulting in overly generalized and outdated content. A significant limitation is that the data have not been continuously updated to reflect recent developments in farm technology and the changing patterns of agrometeorological disasters. These countermeasure data are compiled and reviewed through government-led research initiatives and delivered to farmers via AgEWS. However, this centralized approach leads to infrequent data updates and a structural limitation in evaluating field applicability. Consequently, persistent issues have been raised regarding the countermeasure data’s obsolescence and low effectiveness in practical settings. This issue underscores the urgent need for structural improvements in managing countermeasure data.

2.2.2. Lack of Regional Differentiation in Countermeasures

Currently, AgEWS is established at both municipal [16] and metropolitan levels [17], with local governments taking primary responsibility for its operation and management. By contrast, however, the countermeasure suggestions provided through various AgEWS platforms are based on uniform data supplied by the central government, resulting in a lack of regional differentiation. While the countermeasure suggestions developed and distributed by the central government consider certain variations in crop and climatic characteristics, they fail to sufficiently reflect regional differences in cultivation environments and agricultural practices. As a result, it is not easy to develop tailored response strategies that account for individual farm conditions. For example, Jeju Island has distinct differences in soil, airflow, and cultivation base conditions compared to inland areas due to its volcanic rock terrain and strong coastal exposure. Due to these characteristics, even if the same meteorological disaster, such as a flood or wind damage, is predicted, the response methods required by the region are bound to differ significantly. Nevertheless, the current response guideline service uniformly provides countermeasures according to meteorological disaster type to all regions nationwide and thus has structural limitations in not reflecting such differences in cultivation environments between regions. This limitation ultimately reduces the applicability of the countermeasure suggestions in the field and may limit their acceptance by farmers [18].

2.2.3. Lack of Granularity in Countermeasure Data

The current structure of countermeasure data (Table 1) fails to adequately reflect variations in cultivation season, environmental conditions, and crop varieties, and it also falls short in providing countermeasure data differentiated by the level of agrometeorological disaster. For instance, northern and southern types of garlic are classified as the same crop. However, their cultivation seasons differ significantly, leading to seasonal climatic conditions and phenology differences. As a result, even at the same growth stage, their vulnerability to agrometeorological disasters may vary, necessitating differentiated countermeasures. However, under the current structure, such varietal and cultivation-specific differences are not considered, resulting in the application of uniform countermeasures across all situations. In addition, although AgEWS classifies disaster risk into multiple stages, such as ‘normal’, ‘advisory’, and ‘warning’, the corresponding countermeasure data provide the same countermeasure recommendations regardless of risk level, indicating a lack of differentiation based on severity (Figure 2).

2.2.4. Lack of Scalability Due to a Closed System Architecture

AgEWS was developed without data standardization, resulting in terminology and data formats not complying with public standards. Despite referring to the same concepts, different modules employ inconsistent terminology, reflecting the absence of a unified data definition scheme. Consequently, each time data are exchanged between modules, format conversions and manual mappings are required. This repetitive process increases system complexity and reinforces module-level dependencies, contributing to a closed system architecture. Such a closed structure interrupts interactions with external systems and serves as a key limitation to the scalability and reusability of data within AgEWS. To interact with external platforms, separate mapping tables must be created to accommodate differing terms and formats across systems, resulting in significant inefficiencies in data processing and system integration. To address these challenges, it is necessary to establish data standardization to minimize the need for mapping tables and fundamentally enhance compatibility and interoperability across systems.

2.2.5. Lack of Independence of the Module Due to the Monolithic System Structure

AgEWS has a monolithic structure, meaning its functions, including production, countermeasure data management, and notification sending, are integrated into a single application. This raises a structural limitation that it is not easy to modify or develop a countermeasure function without affecting the whole AgEWS system.

Also, all data, including countermeasure data, are managed in a single AgEWS database, with a close relationship between tables. Modifying the table and database structure is difficult because it directly affects the whole system.

Therefore, countermeasure functions must be isolated as a distinct module and re-structured as an independent system to manage countermeasure data more efficiently and flexibly.

2.3. Improvements

The existing countermeasure function, which has been operated as a subordinate in AgEWS, has had several problems, such as a lack of updated data, regional differentiation, granularity, scalability, and independence [19]. Accordingly, this study derives an improvement direction by separating the countermeasure module and converting it into an independent platform.

2.3.1. Enhancing the System for Managing and Updating Region-Specific Countermeasure Data

This study designed AgCP to achieve a system for timely data updating and regional-specific data management and to overcome the limitation due to a monolithic structure [20]. The design makes AgCP a participative platform that allows various types of users, such as the central government, local government, and farmhouses, to access and customize countermeasure data. The platform supports each user group in managing countermeasure data more efficiently and registering and modifying the data for their jurisdiction.

2.3.2. Enhancing Granularity in Countermeasure Data

The data structure is redesigned by introducing additional granularity criteria based on cultivation characteristics and risk levels to provide more sophisticated countermeasures tailored to diverse situational conditions. This allows for the development of differentiated countermeasures even under the same crop and disaster conditions, depending on the cultivation environment and the severity of the disaster.

2.3.3. Enhancing Data Standardization and Interoperability

To resolve the scalability constraints caused by the existing system’s closed structure, data have been standardized into a structure that complies with public data standards and code systems. An expandable structure has been designed to support organic API linkage with external systems, securing interoperability with various agricultural information systems (Figure 3).

2.3.4. System Architecture Configuration

AgCP has been designed based on MSA, which is optimized for a cloud environment to provide stability and flexibility for all of the features mentioned in Section 2.3. By designing a flexible architecture in which each functional module is managed independently, it is possible to minimize the impact of service changes or expansions on the overall system while simultaneously ensuring data quality, usability, and system interoperability [19,20,21].

3. Design of AgCP

3.1. Countermeasure Data Standard Model

3.1.1. Targets of Data Standardization

Data standardization is imperative for AgCP to operate independently of the existing AgEWS and efficiently integrate with various public and private agricultural management platforms. By consistently managing data definitions, formats, and values, data standardization ensures interoperability and scalability between systems [22,23,24].

In South Korea, public data standardization is formally governed by the Common Standard Terminology with a three-level hierarchical framework, national-level, institutional-level, and application-level, as stipulated in Article 23 of the Act on Promotion of the Provision and Use of Public Data (the “Public Data Act”) and operationalized through the Guidelines on Database Standardization for Public Institutions [25]. This tiered structure is designed to guarantee semantic consistency across administrative units, enabling all users to interpret and utilize public data uniformly [26].

Following this Common Standard Terminology Framework in South Korea, this study adopts a data model that conforms to these three standardization tiers (Figure 4). First, the National Standard Dictionary (Level 1), universally utilized across administrative bodies, encompasses standard terms, domains, and codes. This includes standards such as the National Spatial Data Standard established by the Ministry of Land, Infrastructure and Transport and the Public Data Standard designated by the Ministry of the Interior and Safety. Second, the Institutional Standard Dictionary (Level 2) contains specialized terminology and structural definitions developed for specific institutional domains, such as databases maintained by institutions like the Rural Development Administration (RDA). Third, the Application Standard Dictionary (Level 3) defines detailed terminologies and code systems tailored to specific service objectives, like AgCP.

AgCP proposed in this study adopts higher-level national and institutional standards as a basis. It also defines terms and codes specific to agrometeorological disaster countermeasures as part of its Application Standard Dictionary. In particular, customized terms related to crop type, growth stage, disaster type, and response timing were established to ensure semantic clarity and system flexibility, thereby supporting seamless integration and interoperability with other information systems (

Table 2. Example terms from the Application Standard Dictionary for AgCP.

Standard Term	Standard Term Abbreviation	Lowercase Form	Source
Weather	WTHR	wthr	National Standard
Farmhouse	FRMHS	frmhs	RDA Institutional Standard
Step	STEP	step	National Standard
Countermeasure	CNTRMSR	cntrmsr	RDA Institutional Standard
Classification	CLSF	clsf	National Standard
Growth	GRWH	grwh	RDA Institutional Standard
City and County	SIGUN	sigun	Application Standard
Province	SIDO	sido	Application Standard
Crop	CROP	crop	National Standard
Cultivation	CTVT	ctvt	RDA Institutional Standard
Disaster	DSTR	dstr	National Standard
Suggestion	MANUAL	manual	RDA Institutional Standard
Customization	CUSTOM	custom	Application Standard
Region	RGN	rgn	National Standard
Identifier	IDNTF	idntf	National Standard

).

3.1.2. Enhanced Granularity Data Model for Countermeasures

Differentiated suggestions based on variables such as crop type, cultivation environment, growth stage, disaster type, and risk level are essential to provide precise and context-sensitive countermeasures for agrometeorological disasters. Accordingly, the data structure was designed based on the following granularity criteria (

Table 3. Granularity criteria for structuring countermeasure data modeling.

Entity Name	Design Purpose
Crop Type	Serves as the primary classification criterion for countermeasure suggestions
Cultivation Attribute	Differentiates suggestions based on cultivation conditions such as cultivar, maturity, planting period, and region
Growth Stage	Requires different countermeasures depending on the crop’s growth stage, even for the same disaster
Disaster Type	Organizes countermeasures according to the type of agrometeorological disaster
Risk Level	Provides appropriate countermeasures based on the severity of the disaster

).

Based on these criteria, the countermeasure dataset is modeled around two core entities, the Original Countermeasure Entity and the Customized Countermeasure Entity (Figure 5). The Original Countermeasure Entity contains standardized guidelines defined by central authorities, structured according to combinations of the above granularity attributes. It includes fields such as response timing category, procedural order, content, source, and year of registration. The Customized Countermeasure Entity allows local stakeholders, including regional governments and individual farms, to tailor central guidelines to their local contexts. This entity references the original countermeasure and regional identifiers and records the time of customization.

3.1.3. Data Model and Entity Design

The data model is comprehensively structured, reflecting the granularity and standardization concepts built upon the above. Conceptual data modeling was conducted based on the Application Standard Dictionary for AgCP, defining entities according to functionality, including user management, spatial data processing, countermeasure administration, history tracking, and notification delivery.

Key entities identified through modeling include Member, Regional Identification Information, Original Countermeasure, Crop Type, Risk Level, Cultivation Attribute, and Meteorological Disaster. The Customized Countermeasure serves as the main entity for user-driven data operations. Action entities include Countermeasure History, Countermeasure Notification Log, and Notification Identification, each generated through user interactions (

Table 4. Entity types and roles derived from conceptual data modeling.

Entity Name	Entity Type	Role
Member	Key Entity	Identifies system users
Regional Identification Information	Key Entity	Identifies spatial units
Crop Type	Key Entity	Classifies crops as the primary basis for countermeasure rules
Risk Level	Key Entity	Classifies disaster severity levels as the primary basis for countermeasure rules
Cultivation Attribute	Key Entity	Classifies environmental and cultivation-specific attributes as the primary basis for countermeasure rules
Meteorological Disaster	Key Entity	Defines types of agrometeorological disasters as the primary basis for countermeasure rules
Original Countermeasure	Key Entity	Stores centrally defined standard countermeasures
Customized Countermeasure	Main Entity	Represents user-specific, localized countermeasures
Countermeasure History	Action Entity	Records revision history of customized countermeasures
Countermeasure Notification Log	Action Entity	Logs notifications related to countermeasure changes
Notification Identification	Action Entity	Tracks confirmation of received notifications by users

).

Each entity’s attributes are determined based on the functional dependencies required for input and output data, and functional dependencies among attributes are analyzed to ensure relational integrity (

Table 5. Key attributes and referential relationships by entity.

Entity Name	Attributes	Referenced Entity
Member	Member ID, Region Identification Code, Password	Region Identification Information
Regional Identification Information	Region Identification Code, Region Level Code, Province Code, City/County/District Code, Town/Township/Neighborhood Code, Village Code, Mountain Status, Parcel Main Number, Parcel Sub Number, Latitude/Longitude	-
Crop Type	Crop Code, Crop Name	-
Risk Level	Risk Level Code, Risk Level Name	-
Cultivation Character	Cultivation Character Code, Cultivation Attribute Name	-
Meteorological Disaster	Meteorological Disaster Code, Meteorological Disaster Name	-
Original Countermeasure	Crop Code, Cultivation Character Code, Meteorological Disaster Code, Risk Level Code, Growth Stage Number, Response Timing Category, Procedural Order, Content, Year of Registration, Source, Usage Status, Creation Timestamp	Crop Type, Cultivation Attribute, Meteorological Disaster, Risk Level
Customized Countermeasure	Crop Code, Cultivation Character Code, Meteorological Disaster Code, Risk Level Code, Growth Stage Number, Response Timing Category, Procedural Order, Region Identification Code, Customized Content, Creation Timestamp	Original Countermeasure
Countermeasure History	Crop Code, Cultivation Character Code, Meteorological Disaster Code, Risk Level Code, Growth Stage Number, Response Timing Category, Procedural Order, Region Identification Code, Member ID, Type of Change, Content Before Change, Content After Change, Creation Timestamp	Customized Countermeasure, Member
Countermeasure Notification Log	Crop Code, Cultivation Character Code, Meteorological Disaster Code, Risk Level Code, Growth Stage Number, Response Timing Category, Procedural Order, Region Identification Code, Member ID, Type of Change, Content Before Change, Content After Change, Creation Timestamp	Countermeasure History
Notification Identification	Crop Code, Cultivation Character Code, Meteorological Disaster Code, Risk Level Code, Growth Stage Number, Response Timing Category, Procedural Order, Region Identification Code, Member ID, Creation Timestamp	Countermeasure Notification Log, Member

). This process eliminates data duplication and secures consistency by applying the database normalization standards (1NF–3NF).

The Member entity defines the user instances responsible for storing and managing customized countermeasures. It references the Regional Identification Information entity to differentiate the data query scope based on each user’s jurisdiction.

The Regional Identification Information entity manages spatial units encompassing everything from administrative districts to branch information. It includes hierarchical attributes such as province, city/county/district, town, and village. For farm-level users, the model allows precise spatial referencing down to specific owned farmland units.

The Original Countermeasure entity stores centrally defined standard countermeasures that serve as the default guidance and suggestion for farmers when predicting agrometeorological hazards. It is the foundational dataset upon which agricultural stakeholders, including local countermeasure administrators, may develop customized responses tailored to local needs.

The Customized Countermeasure entity allows non-central users (e.g., local governments and farms) to establish and store region-specific countermeasure strategies based on the original countermeasures. Each customized record references the original countermeasure, enabling traceability. The platform’s query logic is designed to prioritize customized countermeasures when available and fall back to the original guidelines when no customized version exists.

While the Customized Countermeasure entity oversees the latest localized version of the guidelines, the Countermeasure History entity monitors all user modifications over time. It references the customized countermeasure and includes attributes such as the type of change, the content before and after the change, and the ID of the user who made the modification.

The Countermeasure Notification Log entity manages the change history that is the subject of the notification. Although it has the same properties as the countermeasure history, still, it is designed as a separate entity to account for cases where not all changes are necessarily subject to the notification. The Notification Identification entity stores data only when the user confirms the notification.

Based on this conceptual data modeling and attribute-level normalization, the logical ERD structure of the overall system is illustrated in Figure 6.

3.2. User Structure and Functional Flow

3.2.1. User Types and Roles

AgCP was designed to allow various users to manage and utilize countermeasure data directly. It divides users into three types: central government, local government, and farmhouses. Each user type participates in the platform based on its unique role and authority.

The central government is responsible for establishing the standard definition and overall management of countermeasures, registering new crop or agrometeorological disasters as they develop, and revising or deleting existing countermeasures. The central administrator continuously supplements and discovers countermeasure technologies through research institutes and other sources, reinforcing existing countermeasures or registering new data. In addition, customized countermeasures and change history registered by all users can be monitored by region. Aggregate information, such as the number of changes to customized countermeasures by region and frequently changed response guidelines, can be tracked to obtain information necessary for policies, including disaster-related information by region.

Local governments, at the metropolitan or municipal level, are responsible for developing countermeasures for their jurisdiction. They revise and supplement these countermeasures based on the standard countermeasures registered by the central government, tailoring them to suit the agricultural environment of each region and registering them accordingly. For example, if a region has an agricultural supplies distribution policy, the local government can revise countermeasures reflecting this policy and establish unique countermeasures tailored to the region. These changed countermeasures will be prioritized over the central response guidelines when a weather disaster notification is sent to farms within the jurisdiction.

Farmhouse users, the major players who apply countermeasures in real field work, refer to the standard and locally customized countermeasures developed by the central and local governments and tailor them to fit their cultivation environment. Farmers can register effective countermeasures based on their farming experiences on the platform. Although farmhouse users are allowed to customize their own countermeasures, these user-generated data are strictly applied at the individual level and are not enforced on other users. When a custom countermeasure is registered, other users are notified solely for transparency purposes, not for automatic adoption. This role flow enables the establishment of optimized strategies at the farmhouse level and secures a high level of field applicability.

3.2.2. Use Scenario

The countermeasure data management flow in AgCP has a structure that starts with the central government registering original countermeasure data and then links to other users’ making, sharing, and accommodating the data (Figure 7).

Based on the original countermeasures registered by the central government, local government and farmhouse users can modify the content to generate customized countermeasures tailored to their specific cultivation conditions. Once created, the customized countermeasures are automatically saved and simultaneously recorded as part of the change history.

Customized countermeasures are disseminated to other users through a notification system, and users can view the updates upon logging into the platform. Each change record includes information such as the region, crop, type of agrometeorological disaster, and the content before and after the modification, enabling other users to review and compare the changes. Users may adopt the revised countermeasure for their jurisdiction if deemed relevant.

This user-centered countermeasure management structure goes beyond one-way provision, establishing a cyclical system that enables autonomous knowledge sharing and feedback among users. In addition, since every history of the modified countermeasures is systematically recorded and managed, these records can be utilized to analyze regional response trends and serve as empirical data for policy development, ensuring both the objectivity of countermeasure operations and their applicability for policymaking.

3.2.3. Standard Model for Countermeasure Management Functions

The user behavior-based process extends beyond a simple user experience flow, leading to structural design encompassing data flows within the system and interconnections between functions. Figure 8 presents a data flow diagram (DFD) that formalizes the interactions and data flows among key functions involved in countermeasure management. This diagram visually illustrates how the platform’s core functionalities are organically connected.

The central government initially registers the original countermeasures in the system, which are made available for modification by local governments and farmhouses according to their specific conditions. When a user edits a countermeasure, the updated content is saved in the customized countermeasure repository, and a corresponding entry is automatically recorded in the countermeasure history repository. Once the system detects a change in the countermeasure, it immediately sends notifications to all users except the one who modified. When a recipient checks the notification, this confirmation is logged in the notification identification history repository.

To actualize continuous data updating and provide local customized countermeasures tailored to each jurisdiction, overcoming the limitation of centralized countermeasure data provision conducted by the central government, AgCP is designed to have the core functions listed in

Table 6. Key functional components of AgCP.

Name of Function	Description	Target Problem to Solve
Register Customized Countermeasures	Local government and farmhouse users can create customized countermeasures based on original countermeasures.	The centralized provision of countermeasures by the central government makes it difficult to reflect regional characteristics, posing limitations in developing farm-level response strategies and ensuring field-level acceptance.
Save Countermeasure History	Changes to customized countermeasures are automatically saved to be tracked.	Unable to track countermeasure change history.
Countermeasure Change Notification	Change notifications are delivered to all users, and the identification log is saved once they confirm the notification.	Insufficient information dissemination and lack of updates.
Compare Original and Customized Countermeasures	Allows integrated retrieval and comparison of original and customized countermeasures.	Lack of countermeasure knowledge sharing.

. This standard model is focused on resolving the problem of a lack of updates, which was pointed out as a significant limitation of the existing AgEWS.

These functions do not operate independently but are organically interconnected through data flows within the overarching process of countermeasure management. Based on a user-centered management structure, the entire process is designed as an integrated flow, from countermeasure modification and saving history to change notification and confirmation. Each stage is linked to a separate repository, ensuring data consistency, traceability, and timeliness.

3.3. Standard Open API Model

The existing AgEWS system has had difficulties in data interoperability with other external systems due to its closed system structure, and this limitation has functioned as a significant factor in disrupting data reusability. AgCP has standardized its internal data based on the public data standard system to solve the interoperability problem. Key terms contained in countermeasures, such as crop, cultivation attribute, agrometeorological disaster, and risk level, have been codified according to a data standard, and this standard system makes AgCP interoperable with other information systems without mapping for terms and format.

A RESTful Open API integration method was adopted to enable standardized, real-time access to AgCP by various external agriculture-related platforms, including AgEWS. The API is designed to provide optimized countermeasure suggestions tailored to a specific region or user based on request parameters, and it allows external systems to utilize the information for policy decision support or the development of customized alert services.

The API for retrieving countermeasures adopts a query string request method, allowing clients to pass only the required parameters selectively. This design enables the API to remain consistent without modifying the endpoint, even if the underlying database schema is expanded or changed in the future. The response is returned in the form of a JSON array, making it efficient for the calling system to collect and process the data.

Table 7. Parameters to request the countermeasure API.

Parameter	Required	Description	Data Type	Example Values and Validation Rules
crop	mandatory	crop code	String	4-digit code *
cultivationCharacter	optional	cultivation character code	String	3-digit code (e.g., common: c01, early ripening: c02)
growthStage	optional	growth stage of crop	Integer	Min value: 0
agrometeorologicalDisaster	mandatory	disaster code	String	6-digit code **
riskLevel	optional	risk level code	Integer	1-digit code (e.g., normal: 1, advisory: 2, warning: 3)
responseType	optional	preparedness, response, recovery	enum	One of: preparedness, response, recovery format: lowercase string
regionalLevel	optional	metropolitan, municipality, farm	String	2-digit code (e.g., metropolitan: L1, municipality: L2)
region	conditional	PNU	String	Parcel code (PNU); required when the regional level parameter is specified.

* 2-digit category code + 2-digit item code based on the standard crop classification system provided by the Ministry of Agriculture, Food and Rural Affairs of Korea. ** The agrometeorological disaster code follows the code system defined in the AgEWS.

summarizes the available query parameters that can be provided by the client during an API call, distinguishing between required and optional fields. This structure supports flexible data retrieval based on various combinations of conditions.

Table 8. Countermeasure API response example.

Response Code

Response Example

200

{  "statusCode": 200,  "message": "success",  "items": {   "query": {    "cropCode": "0601",    "disasterCode": "001001"   },   "result": [    {    "cropName": "Apple",    "cultivationCharacter": "Early Ripening",    "growthStepName": "Fruit Enlargement Stage",    "disasterName": "Wind Damage",    "riskStepName": "Warning",    "responseTypeName": "Preparedness"    "countermeasures": [     " Installation of windbreak forests, windbreak walls, and wind     break nets"     ]     },    ...   ]   } }

presents an example of an actual API response, presenting the structure of the data returned in JSON format based on the input parameters provided to the countermeasure API.

Table 9. Comparison of key features between the legacy API and the proposed AgCP API.

Feature	Legacy API	AgCP API
Authentication	API Key	OAuth 2.0
Query Flexibility	Limited requests with fixed parameters	Dynamic queries using a combinable set of optional parameters
Extensibility	The endpoint must be modified if schema changes	The endpoint remains stable even if the schema changes
Interoperability	Uses internal codes	Adopts public data standard codes and domains

compares the functions of the existing AgEWS API and the AgCP API designed in this study. In terms of authentication method, query flexibility, extensibility, and interoperability, the AgCP API shows improvements in structural flexibility and interoperability. This enables connectivity with external platforms and provides a technical foundation for users to flexibly view and utilize countermeasure data according to their purposes.

This API is used to visualize response data in a form that can be immediately applied to the user interface by linking it with the front-end interface in applications that request this API, including AgEWS web services and mobile services. For example, the countermeasures array in the JSON response is displayed in various ways, allowing users to intuitively understand the recommended response guidelines and apply them in the field.

Figure 9 illustrates the process by which the response guideline API is invoked based on user input, and the response is displayed on the mobile application screen. The user selects the desired conditions, such as crop, cultivation characteristics, growth stage, and disaster risk, from the top input menu, and the corresponding selection value is transmitted as an API request parameter. The returned JSON response is then classified into response guidelines by disaster type and response type (preparedness, response, recovery) stages according to the parameters and is visualized in the form of a card on the user interface. Through this, the user can intuitively check the response guideline that suits their farm situation and immediately apply it to the field.

The proposed platform, AgCP, overcomes the limitations of the existing AgEWS, which has been structured as a closed and monolithic system. It is designed as an open architecture that ensures interoperability with various systems within the agricultural data ecosystem, enabling countermeasure data to be reused as a core public resource.

3.4. Cloud-Based Microservices Architecture Model

The cloud environment provides a structure that enables elastic extension and reduction of resources without dependency on a physical server and stable service operation in significant traffic fluctuations. Agrometeorological disasters tend to break out in specific periods according to seasonal and regional conditions, which may cause a rapid rise in the registration of customized countermeasures and notification requests. Considering this background, a flexible resource operating based on the cloud infrastructure is effective for system availability and performance maintenance.

AgCP involves various user types, including the central government, local governments, and farmhouses, each participating in countermeasure registration, retrieval, modification, history recording, and notification dissemination functions. Rather than building these features within a single integrated system, the platform adopts a microservices architecture in which each function is designed as an independent service. This approach enhances system flexibility, operational stability, and functional independence (Figure 10).

Accordingly, each service is responsible for its own data flow and is implemented to allow independent deployment, scaling, and fault handling at the service level. By default, functionally related features are grouped when separating services. However, when multiple functions must be handled within a single transaction, they are combined into one service to ensure the properties of ACID (atomicity, consistency, isolation, and durability). Service boundaries are defined based on functional domain responsibilities rather than user roles, and user-specific access is handled internally through role-based access control (RBAC).

In this architecture, core components, including countermeasure management, notification service, authentication/authorization, and member management, are logically separated and deployed as independent containers, enabling a flexible response through auto-scaling at the service level when needed. All external requests are routed through an API gateway, where the access token issued by the authentication/authorization service is validated. The authentication/authorization service is responsible for issuing, validating, and refreshing JSON Web Token (JWT), which encodes user identity and role metadata (e.g., central government, local government, and farmhouse), in compliance with the OAuth 2.0 protocol. Based on this token, the platform implements RBAC, which restricts access to APIs and data according to the user’s privileges. For instance, farmhouse users are permitted to retrieve and modify only their own countermeasure records, while local government users have access to their jurisdictional data. These access controls are consistently enforced across all microservices via token inspection and internal role-based policies, ensuring secure and compliant user-specific data access.

When a user registers a customized countermeasure, the process proceeds sequentially from registration to notification dissemination. Registration and history recording must be treated as a single ACID transaction and handled within the same service. By contrast, the notification function, which requires real-time processing and involves more complex logic, is implemented as a separate service. The notification service asynchronously receives registration or update events from the countermeasure management service via a message queue (MQ) and is responsible for sending notifications and storing notification logs. To reduce service coupling and improve maintainability, the notification service does not directly access countermeasure data but processes events solely based on the information received.

The notification service asynchronously receives event messages from the countermeasure management service via a Kafka-based message queue system, optimized for high throughput. To enhance the robustness of message delivery, the system employs a message acknowledgement mechanism and at-least-once delivery semantics. In the event of a message processing failure, Kafka’s built-in retry mechanism ensures that unprocessed messages are retained in the queue and re-consumed upon service recovery. This fault-tolerant design minimizes the risk of message loss and enables reliable operation even in the event of failures.

Each microservice has its own logically separated database, with read/write permissions restricted to the tables relevant to its functional responsibilities. The countermeasure management service manages original countermeasures, customized countermeasures, and countermeasure history. The notification service manages notification and identification logs, while the member management service is responsible for member and regional information. Other services requiring user information can be accessed indirectly via internal API calls.

Through this architecture, the platform achieves the key advantages of microservices: scalability at the function level, fault isolation, data responsibility separation, and enhanced security. In particular, by minimizing service coupling and ensuring each function maintains its transaction and data boundary, the system allows individual services to be added or modified without impacting the entire system. This structure provides scalability and maintainability, enabling seamless integration of new services or user types without altering the existing platform architecture.

4. Conclusions and Discussion

This study addressed the limitations of the countermeasure service embedded in the existing AgEWS, which had been structured as a document-based, centrally managed, and monolithic module. It lacked data recency, granularity, and regional adaptability, limiting its applicability in real-world agricultural settings. Furthermore, the closed architecture of the system posed significant technical barriers to interoperability with external platforms.

To overcome these limitations, this study proposed the architectural separation of the countermeasure function from AgEWS and the development of an independent, cloud-based platform capable of managing user-customized data in real time. The platform was designed to address granularity issues by redefining the data schema using key attributes such as crop type, cultivation characteristics, growth stage, disaster type, and risk level. Additionally, a standardized data model was established to support external system integration. User-specific scenarios were also analyzed and incorporated into the platform’s functional design, enhancing field-level customization and responsiveness.

The resulting platform provides a technical foundation for the real-time management and dissemination of regionally tailored countermeasures, from the central government to individual farms, ensuring both data currency and field applicability. However, it must be noted that the existing countermeasure datasets maintained by national research institutions were constructed initially under the simplified data structure of the legacy AgEWS. Therefore, a comprehensive review and reconfiguration of the existing countermeasure data are required to operationalize this enhanced platform fully.

Currently, RDA is implementing a project to supplement the countermeasure data built within AgEWS and to establish AgCP, a platform for managing countermeasure data at a regional scale, based on the new countermeasure database, linking it with AgEWS. The AgCP design proposed in this study can serve as a foundation that aligns with both national policy directions and technical requirements. In fact, a pilot version of AgCP based on this design is scheduled for launch in 2026.

Looking forward, countermeasure suggestions should be systematically restructured to reflect cultivation attributes and risk levels by crop type and to subdivide the guidelines and recommendations according to the data structure. Moreover, suppose research into integrating farm-level resource data, such as agricultural facilities and inputs, is enabled. In that case, it will be possible to provide more precise, resource-aware countermeasure services that reflect the resource status of farms. Furthermore, by integrating generative AI into the platform, it is expected that the service can be expanded into an intelligent system in which farmhouses can obtain context-specific countermeasure information through conversational queries, rather than manually selecting conditions. This would enable users to access appropriate countermeasure suggestions in natural language, enhancing accessibility and usability.