Smart farming platforms are becoming central infrastructures for digital agriculture because they connect field-level sensing, machinery records, farm-management information systems, remote sensing inputs, advisory services, analytics modules, and decision-support tools. Yet many platforms remain limited by fragmented data flows, incompatible formats, weak semantic alignment, uneven governance arrangements, and poor integration with farm decision workflows. This article develops an interoperable reference architecture for smart farming platforms. The approach is conceptual and architecture-oriented: it synthesises platform, IoT, farm-management, interoperability, analytics, and governance concerns into a layered architecture that clarifies how heterogeneous agricultural data and services can be connected, interpreted, governed, analysed, and reused. The proposed architecture includes physical sensing and machinery, connectivity and edge computing, data ingestion, APIs and integration, data standardisation and semantic interoperability, storage and governance, analytics and AI, decision-support and visualisation, farm-management workflow, stakeholder interface, security and access control, and monitoring and feedback layers. The contribution is a structured architecture that distinguishes data connectivity, API access, syntactic compatibility, semantic interoperability, governance, analytics integration, and workflow usability. The article argues that interoperable smart farming platforms should not be treated as simple data repositories or dashboards; rather, they require modular, auditable, secure, and context-sensitive integration across technical and organisational boundaries. The architecture supports researchers, platform developers, machinery manufacturers, FMIS providers, advisors, cooperatives, and policymakers in designing more coherent digital agriculture ecosystems.
Smart farming platforms have become core infrastructures in digital agriculture because they are expected to organise heterogeneous data, coordinate multiple technologies, and support more informed farm-management decisions. The reviewed smart farming literature shows that digital agriculture depends on data streams generated by sensors, machinery, remote sensing systems, farm records, advisory systems, and analytics tools, but these streams do not automatically become usable knowledge when they are merely collected in a shared environment [1–3]. For this reason, smart farming platforms should be understood as data ecosystems in which technical connectivity, data management, institutional arrangements, and user practices interact.
The integration challenge is not only technological. IoT-based food and farm systems have been examined through architecture frameworks precisely because device connectivity, data exchange, service coordination, and decision support require structured system design rather than ad hoc platform assembly [4]. In smart farming, a platform that receives data from a soil probe, a tractor terminal, a weather service, a satellite image, and an FMIS must make these data technically accessible, syntactically manageable, semantically interpretable, governable, and usable within farm operations.
Interoperability therefore matters because smart farming increasingly depends on cross-system data reuse. A yield monitor may produce spatially referenced observations, a sprayer may generate variable-rate application records, a weather station may provide high-frequency time series, and an FMIS may store field boundaries, crop plans, input records, and advisory notes. Without an architecture that clarifies how these elements are connected, standardised, governed, and translated into decisions, platform integration can remain limited to data aggregation rather than meaningful operational interoperability [1].
This article develops an interoperable reference architecture for smart farming platforms. The aim is not to present a software implementation, empirical benchmark, vendor comparison, or universal platform prescription; instead, it proposes a conceptual architecture that clarifies platform layers, data flows, interoperability mechanisms, governance responsibilities, analytics integration, and decision-support functions. Such a reference architecture is useful because it provides a reusable design logic that can be adapted to diverse farm contexts, technology portfolios, institutional arrangements, and data-governance requirements [4].
Smart farming platforms can be defined as integration systems that connect field-level data sources, machinery systems, farm-management records, remote sensing inputs, advisory knowledge, analytics modules, and decision-support interfaces. Their function is broader than storing data in a central repository because they must coordinate interactions among devices, software services, users, data standards, governance rules, and decision contexts. Recent smart farming scholarship shows that smart farming systems combine sensing, connectivity, automation, information processing, and decision support across diverse agricultural operations [5].
Data aggregation, interoperability, analytics integration, and workflow integration are related but distinct platform functions. Data aggregation refers to collecting information from different sources; interoperability concerns whether systems can exchange, interpret, and reuse data across technical and organisational boundaries; analytics integration concerns whether data can support descriptive, predictive, or prescriptive reasoning; and workflow integration concerns whether outputs are embedded in farm planning, field operations, advisory routines, and recordkeeping. Crop data management is therefore a platform-level function because data must be prepared, contextualised, and maintained across the farm-data lifecycle before it can support operational decisions [6].
The value of a smart farming platform depends on modularity because agricultural technologies evolve at different speeds and are adopted in diverse combinations. Sensors, machinery terminals, FMIS tools, drone imagery, satellite products, advisory portals, and analytics modules may enter the platform ecosystem through different vendors, data formats, update cycles, and ownership arrangements. Agriculture 4.0 scholarship emphasises that smart farming depends on multiple enabling technologies, which means that platform design should support modular integration rather than assume one closed system can provide all capabilities [7].
However, modularity alone is insufficient. Platform usefulness also depends on data quality, governance, usability, and decision relevance. Poorly documented sensor readings, inconsistent field identifiers, missing timestamps, unclear data rights, inaccessible APIs, or dashboards disconnected from farm routines can all reduce the value of technically integrated systems. A smart farming platform should therefore be designed as an adaptive integration environment that supports data movement, shared meaning, trustworthy governance, analytical reuse, and practical decision-making [6].
The physical sensing and machinery layer of a smart farming platform includes IoT sensors, soil sensors, weather stations, livestock and crop-monitoring devices, machinery telemetry, yield monitors, and variable-rate application systems. These systems generate data with different temporal frequencies, spatial granularities, calibration needs, and operational meanings. Agricultural IoT research shows that connected sensing can support monitoring and automation, but it also introduces challenges related to device heterogeneity, deployment conditions, communication reliability, and data integration [8].
Sensor and device data usually require preprocessing before they can be used in analytics or decision support. Raw observations may need timestamp alignment, spatial referencing, unit conversion, anomaly detection, missing-value handling, and contextual linkage to fields, crops, operations, or management zones. IoT and data analytics research in agriculture highlights that value emerges when data collection is connected to analysis and interpretation rather than treated as a separate technical endpoint [9]. This makes the data ingestion layer essential for transforming physical signals into platform-ready information.
Machinery telemetry, yield monitor data, and variable-rate application records add further integration complexity because they are often linked to equipment-specific systems, field operations, geospatial paths, and proprietary data structures. Smart farming IoT solutions demonstrate that device ecosystems differ in sensing functions, connectivity arrangements, data models, and deployment architectures, so platforms must be prepared for heterogeneous machine-generated data rather than assuming uniform data streams [10]. Integration must therefore address not only data availability but also operational context, spatial reference systems, equipment metadata, and task-specific meaning.
Farm-management information systems and advisory records form another critical input category because they connect platform data to planning, compliance, agronomic interpretation, and management routines. FMIS research shows that these systems include diverse functions such as recordkeeping, planning, monitoring, reporting, and decision support, but they also face obstacles related to usability, data entry burden, integration, and alignment with farm workflows [11]. As a result, smart farming platforms should treat FMIS integration as a workflow and organisational challenge, not merely as a database-connection task.
Table 1 summarises the major smart farming platform input systems that require integration across sensors, machinery, remote sensing, and farm-management systems.
Table 1. Smart Farming Platform Input Systems Requiring Integration: IoT Sensors, Machinery Telemetry, Yield Monitors, Variable-Rate Application Records, Remote Sensing, Weather Data, Soil Data, Farm-Management Information Systems, and Advisory Records
Input system | Typical data generated | Data format or structure | Temporal frequency | Spatial granularity | Integration challenge | Data-quality concern | Platform role | Decision-support relevance |
IoT field sensors | Soil moisture, temperature, humidity, crop microclimate, water status | Time-series observations, device logs, sensor metadata | High-frequency to periodic | Point, zone, or field level | Device heterogeneity, communication gaps, calibration differences | Missing values, drift, sensor failure, inconsistent units | Provides continuous field-condition monitoring | Supports irrigation, stress detection, and operational alerts |
Weather stations | Rainfall, wind, temperature, humidity, solar radiation | Time-series data with station metadata | High-frequency to daily summaries | Station, farm, or local area | Linking station data to fields and operations | Sensor exposure, missing periods, local representativeness | Adds environmental context to farm decisions | Supports spraying windows, irrigation planning, and risk alerts |
Soil data systems | Soil texture, nutrients, pH, organic matter, compaction, electrical conductivity | Laboratory records, spatial layers, sampling grids, maps | Seasonal, annual, or periodic | Point, grid, zone, or field level | Aligning sampling schemes with field boundaries and management zones | Sampling bias, inconsistent laboratory methods, outdated layers | Provides baseline biophysical context | Supports fertilisation, zoning, crop planning, and soil management |
Farm machinery telemetry | Machine location, operation status, fuel use, implement activity, task logs | Geospatial logs, machine messages, equipment metadata | Real time, per operation, or batch upload | Path, field, machine, or operation level | Proprietary formats, equipment-specific identifiers, connectivity variation | Incomplete task records, inconsistent implement metadata | Connects field operations to digital records | Supports operation monitoring, traceability, and logistics |
Yield monitors | Yield, moisture, harvest location, crop flow observations | Georeferenced point or raster-like harvest records | Per harvest operation | Path, grid, zone, or field level | Cleaning, calibration, spatial alignment, boundary matching | Outliers, lag effects, sensor calibration errors | Provides outcome data for performance interpretation | Supports yield mapping, zone evaluation, and management review |
Variable-rate application systems | Prescription maps, applied rates, input type, application location | Geospatial prescriptions and as-applied records | Per application operation | Grid, zone, path, or field level | Reconciling planned and actual application records | Missing as-applied data, unit inconsistency, boundary mismatch | Links recommendations to executed operations | Supports input optimisation, compliance records, and adaptive management |
Remote sensing systems | Vegetation indices, canopy condition, thermal indicators, imagery-derived layers | Raster imagery, processed layers, metadata | Event-based, periodic, or seasonal | Pixel, zone, field, or landscape level | Cloud cover, resolution differences, georeferencing, temporal matching | Atmospheric effects, classification error, inconsistent preprocessing | Adds spatial monitoring beyond ground sensors | Supports crop monitoring, scouting prioritisation, and anomaly detection |
Farm-management information systems | Field records, crop plans, input records, labour tasks, compliance documents | Relational records, forms, calendars, field-boundary files | Continuous, seasonal, or event-based | Farm, field, crop, enterprise, or task level | Workflow alignment, duplicate entry, inconsistent identifiers | Incomplete records, manual-entry errors, outdated plans | Organises operational and administrative farm data | Supports planning, reporting, traceability, and management decisions |
Advisory records | Recommendations, scouting notes, risk assessments, agronomic observations | Text notes, reports, structured forms, attachments | Event-based or seasonal | Field, crop, farm, or advisory territory | Combining expert interpretation with platform data models | Ambiguity, inconsistent terminology, limited metadata | Adds human expertise and contextual interpretation | Supports advisory decisions, farmer communication, and action prioritisation |
APIs provide controlled mechanisms through which software systems can request, exchange, update, and reuse agricultural data. In a smart farming platform, an API layer can connect sensor services, machinery data portals, FMIS tools, analytics modules, advisory applications, and dashboards, but API access should not be mistaken for full interoperability. The AgDataBox API demonstrates the importance of integration mechanisms for precision agriculture data and software, while data-standard and semantic-model research shows that exchange mechanisms require format alignment, metadata, and shared interpretation to become reusable across systems [12–14].
Data standards and metadata support syntactic and contextual consistency. Syntactic interoperability concerns whether data can be exchanged in recognised formats and structures, whereas metadata helps describe units, timestamps, spatial references, sensor properties, field identifiers, crop context, operational events, and data provenance. Data standards can reduce fragmentation by making information more consistent, but they do not remove the need for governance, semantic interpretation, data-quality management, or workflow alignment [13]. Therefore, the architecture should position standards as part of a wider interoperability stack rather than as a standalone solution.
Semantic interoperability is especially important because agricultural data often carry meaning that depends on context. A “field,” “zone,” “operation,” “application,” “yield,” or “recommendation” may be represented differently across machinery systems, FMIS tools, advisory services, and analytics modules. Semantic meta-models for precision agriculture and livestock farming show that integrated data exploitation requires shared concepts and relationships, not only shared files or database fields [14]. Ontologies, controlled vocabularies, metadata models, and semantic mappings can therefore help platforms preserve meaning across heterogeneous systems.
Interoperability should be designed as layered architecture rather than simple file transfer. Recent interoperability architecture work for digital agri-food platforms shows that technical, semantic, organisational, and governance dimensions must be aligned for data and services to move across platform boundaries in reusable ways [15]. This distinction is critical: data connectivity enables access, API integration enables controlled exchange, format compatibility enables parsing, semantic interoperability enables shared meaning, governance enables legitimate use, and workflow integration enables practical decision-making.
Table 2 maps the interoperability layers required for smart farming platforms to exchange, interpret, and reuse heterogeneous agricultural data.
Table 2. Interoperability Layers for Smart Farming Platforms: Technical Connectivity, Data Formats, APIs, Metadata, Semantic Alignment, Data Standards, Governance Rules, Security, Privacy, and Cross-Platform Portability
Interoperability layer | Core function | Technical mechanism | Required metadata or standardization | Main barrier | Governance consideration | Platform design implication | Example integration use |
Technical connectivity | Enables devices, systems, and services to transmit data | Networks, gateways, edge devices, device connectors, communication protocols | Device identity, connection status, timestamp, location, data-source description | Unreliable connectivity, incompatible devices, limited rural infrastructure | Responsibility for connectivity failures and data continuity | Design redundant and context-aware connectivity pathways | Connecting field sensors and machinery terminals to platform ingestion services |
Data-format compatibility | Allows systems to parse and structure exchanged data | Common file formats, schemas, database mappings, geospatial formats | Units, field identifiers, coordinate systems, schema definitions | Proprietary formats, inconsistent field names, undocumented structures | Rules for format conversion and data transformation accountability | Include transformation services and schema-validation checks | Importing yield files, prescription maps, and field-boundary records |
API integration | Provides controlled software-to-software exchange | REST APIs, service interfaces, authentication, event-based data exchange | Endpoint documentation, permissions, object definitions, version information | Closed APIs, version changes, weak documentation, uneven access | API access rights, consent, rate rules, audit trails | Use modular API gateways and version-managed interfaces | Linking FMIS records with analytics modules and advisory dashboards |
Metadata management | Describes context, provenance, quality, and meaning | Metadata registries, data catalogues, provenance records | Source, owner, collection method, time, location, processing history, quality flags | Missing metadata, inconsistent terminology, manual-entry burden | Data provenance, accountability, permitted reuse | Make metadata capture part of ingestion and workflow design | Documenting whether a soil layer came from laboratory sampling, sensor data, or model output |
Semantic alignment | Preserves shared meaning across systems | Ontologies, semantic mappings, controlled vocabularies, domain models | Concept definitions, relationship mappings, crop and operation terminology | Different meanings for similar terms across platforms | Agreement on authoritative terms and interpretation rules | Include semantic services between data standards and analytics | Aligning “field operation,” “application,” and “recommendation” across machinery and FMIS tools |
Data standards alignment | Reduces fragmentation across data exchange practices | Standard schemas, domain data models, exchange templates | Standard units, spatial references, crop codes, operation categories | Partial adoption, local adaptation, vendor divergence | Standard-selection authority and update responsibilities | Design standards support without locking the architecture to one format | Exchanging field boundaries, machinery records, or advisory observations across platforms |
Governance rules | Defines legitimate data access, control, sharing, and reuse | Permission models, consent records, data-use policies, audit logs | Ownership, access rights, purpose of use, retention rules | Unclear data rights, weak transparency, misaligned incentives | Farmer control, benefit sharing, institutional accountability | Embed governance services across ingestion, APIs, storage, and analytics | Controlling advisor, cooperative, machinery-provider, and researcher access to farm data |
Security and privacy | Protects systems, data, and users from misuse or attack | Authentication, authorisation, encryption, monitoring, secure logging | User identity, role definitions, sensitivity tags, access history | Cybersecurity threats, weak credentials, poorly secured devices | Privacy protection, incident accountability, access-control enforcement | Treat security as cross-cutting rather than an add-on | Restricting access to machinery telemetry, farm records, and analytics outputs |
Cross-platform portability | Allows data and services to move across platform ecosystems | Export/import services, open interfaces, semantic mappings, data packages | Portable identifiers, standard metadata, provenance, licensing terms | Vendor lock-in, incompatible semantics, incomplete exports | Rights to transfer, reuse, and delete data | Support portability by design through APIs, standards, and governance | Moving farm records, field boundaries, and historical yield data between FMIS providers |
Organisational interoperability | Aligns platform exchange with roles, responsibilities, and workflows | Service agreements, advisory protocols, workflow mappings, data-sharing arrangements | Stakeholder roles, decision responsibilities, process definitions | Misaligned incentives, unclear responsibilities, low trust | Accountability, transparency, benefit distribution | Design platform functions around real farm and advisory processes | Coordinating farmer, advisor, cooperative, machinery dealer, and platform-provider interactions |
The analytics and AI layer of a smart farming platform transforms integrated agricultural data into descriptive, predictive, and prescriptive outputs. Machine-learning applications in agriculture demonstrate that algorithmic methods can support tasks such as crop monitoring, yield estimation, disease detection, irrigation planning, and machinery-related decision support when appropriate data are available and sufficiently prepared [16]. In the proposed architecture, AI modules should therefore be positioned after data ingestion, standardisation, semantic alignment, and governance controls rather than treated as independent tools detached from platform data quality.
Agricultural big-data analysis depends on pipelines that organise data collection, storage, preprocessing, modelling, interpretation, and reuse. Big-data research in agriculture shows that analytical value depends on the ability to manage diverse data sources and analytical practices across farm contexts [17]. For smart farming platforms, this means that analytics integration must include data fusion, provenance tracking, feature preparation, uncertainty handling, and interpretation pathways that connect model outputs to operational decisions.
Decision-support systems form the bridge between analytics outputs and farm action. Agriculture 4.0 decision-support research shows that DSS design must address decision context, usability, system integration, and user interpretation rather than only computational capability [18]. A platform that predicts irrigation demand, disease risk, input requirements, or yield variation is incomplete unless those outputs are translated into recommendations, alerts, maps, scenarios, or advisory explanations that farmers and advisors can evaluate.
AI integration should remain auditable, human-centred, and sensitive to agricultural context. Interdisciplinary work on AI in agriculture indicates that intelligent systems must account for ethical, social, organisational, and domain-specific considerations rather than assuming that algorithmic outputs automatically improve decisions [19]. In a smart farming platform architecture, analytics modules should therefore include traceability, uncertainty communication, feedback capture, and mechanisms for farmer or advisor oversight.
Data governance is a core architectural requirement because farm data are generated through relationships among farmers, machinery providers, platform operators, advisors, cooperatives, researchers, and technology vendors. Research on farmers and smart farming data shows that data sharing is shaped by legal uncertainty, trust, control, and concerns about how data may be accessed or reused [20]. A reference architecture must therefore specify ownership, access rights, permissions, consent, retention, provenance, and permitted reuse rather than assuming that all integrated data are freely available for platform analytics.
Transparency and accountability are equally important because platform users need to understand how data are used and who benefits from data exchange. Work on trust, transparency, and benefit-sharing in smart farming shows that farmers may be reluctant to participate in digital systems when data-use practices are unclear or when benefits are unevenly distributed [21]. Smart farming platforms should therefore include user-visible governance functions, audit trails, benefit-sharing logic, explainable data-use policies, and mechanisms for correcting or contesting data errors.
Security, privacy, and access control must operate as cross-cutting architectural services. Security and privacy research in smart farming identifies risks associated with connected devices, data transmission, cloud services, access management, and sensitive farm information [22]. The architecture should embed authentication, authorisation, encryption, role-based access, secure API management, privacy safeguards, and monitoring across device, connectivity, storage, analytics, and decision-support layers.
Platform resilience also requires monitoring and feedback mechanisms that detect technical faults, cybersecurity threats, data-quality problems, and workflow breakdowns. Agricultural IoT security research shows that smart farming environments face threat surfaces across sensors, networks, devices, applications, and data services [23]. A robust architecture should therefore include anomaly monitoring, incident logging, device-status tracking, security updates, and feedback from users and field outcomes so that the platform can learn from operational experience without claiming automatic optimisation.
The proposed interoperable reference architecture links technical platform layers to farm-management workflows and governance responsibilities. FMIS reference architecture research supports the need to connect platform design with planning, recordkeeping, operational coordination, and decision processes, while smart farming data-management and analytics-platform research supports explicit layers for ingestion, storage, governance, analytics, and modular service integration [24–26]. On this basis, the architecture is organised as a layered system rather than a single database, dashboard, or analytics engine.
The lower layers consist of physical sensing and machinery, connectivity and edge computing, and data ingestion. The physical layer includes IoT sensors, soil systems, weather stations, farm machinery, yield monitors, variable-rate application records, remote sensing, FMIS records, and advisory inputs. The connectivity and edge layer manages device communication, local preprocessing, buffering, and context-aware routing. The data ingestion layer validates, cleans, timestamps, spatially references, and prepares data for platform use. Platform-selection research for precision farming data analytics indicates that feasibility, modularity, scalability, and platform fit should be considered when designing or selecting such components [27].
The middle layers include API and integration services, data standardisation, semantic interoperability, storage, governance, security, privacy, and access control. The API layer enables controlled exchange among software modules, FMIS tools, advisory services, machinery providers, and analytics components. The semantic layer aligns field identifiers, crop terms, operations, prescriptions, observations, and recommendations across systems. Digital data-platform research for small farmers shows that platform usefulness depends on turning integrated data into decision-support functions that are accessible to users rather than remaining hidden in technical back-end systems [28].
The upper layers include analytics and AI, decision support and visualisation, farm-management workflow integration, stakeholder interfaces, and monitoring, feedback, and learning. The analytics layer supports data fusion, descriptive monitoring, predictive modelling, risk alerts, and advisory interpretation. The decision-support layer translates analytical outputs into maps, alerts, recommendations, scenarios, and dashboards. Digital twin research in smart farming supports the value of feedback loops that connect digital models, platform data, field conditions, and decisions over time [29].
The architecture should distribute functions across edge and cloud environments according to latency, connectivity, scalability, and operational needs. Edge-cloud smart farming platform research shows that some functions can benefit from local processing near field devices, while other services may require cloud-based storage, integration, analytics, and coordination [30]. The proposed architecture therefore avoids assuming that cloud or edge computing is inherently superior; instead, it treats edge-cloud coordination as a design choice shaped by farm context, data sensitivity, communication reliability, decision urgency, and implementation capacity.
Table 3 presents the proposed interoperable reference architecture for smart farming platforms by linking architectural layers to integration functions, governance needs, and decision-support outputs.
Table 3. Proposed Interoperable Reference Architecture for Smart Farming Platforms: Sensing and Machinery Layer, Connectivity Layer, Data Ingestion Layer, API Layer, Semantic Interoperability Layer, Governance Layer, Analytics Layer, Decision-Support Layer, and Farm Workflow Layer
Architecture layer | Core function | Primary data inputs | Key interoperability requirement | Security or governance requirement | Analytics contribution | Decision-support output | Main users | Implementation risk |
Physical sensing and machinery layer | Captures field, machine, environmental, and operational data | IoT sensors, soil sensors, weather stations, machinery telemetry, yield monitors, variable-rate records | Device identification, consistent timestamps, spatial referencing, equipment metadata | Device ownership, data-source authentication, protection against tampering | Provides raw observations for monitoring and modelling | Field-condition evidence, operation logs, machinery status | Farmers, machinery operators, sensor providers, machinery manufacturers | Device heterogeneity, calibration problems, missing data, proprietary systems |
Connectivity and edge layer | Transfers data and performs local processing where needed | Sensor signals, machinery logs, local weather data, remote field observations | Communication protocols, gateway compatibility, edge-service interfaces | Secure transmission, gateway access control, local data protection | Enables local filtering, buffering, and preprocessing | Timely alerts, local operational continuity, reduced dependence on continuous connectivity | Farmers, platform developers, connectivity providers | Rural connectivity gaps, gateway failures, uneven edge capacity |
Data ingestion layer | Converts incoming data into platform-ready information | Device streams, machine files, imagery layers, FMIS exports, advisory records | Schema validation, unit harmonisation, geospatial alignment, temporal alignment | Provenance capture, data-quality logging, ingestion permissions | Creates cleaned and structured datasets for analytics | Reliable data inputs for maps, alerts, dashboards, and reports | Platform developers, data managers, advisors | Incomplete metadata, transformation errors, inconsistent identifiers |
API and integration layer | Enables controlled software-to-software exchange | FMIS data, machinery records, sensor services, analytics services, advisory tools | Stable APIs, endpoint documentation, versioning, authentication | API permissions, audit logs, consent-aware data sharing | Allows analytics modules and external services to access required data | Connected advisory services, integrated dashboards, service interoperability | FMIS providers, platform developers, advisory services, machinery firms | Closed APIs, poor documentation, version changes, vendor lock-in |
Data standardisation and semantic interoperability layer | Aligns formats, meanings, and relationships across systems | Field identifiers, crop codes, operation records, sensor metadata, recommendation terms | Shared vocabularies, semantic mappings, ontologies, standard data models | Stewardship of definitions, accountability for mappings, transparent transformation rules | Improves data fusion and model interpretability | Comparable maps, aligned recommendations, cross-system interpretation | Researchers, platform architects, standards bodies, developers | Partial standards adoption, ambiguous terminology, local variation |
Data storage and governance layer | Stores data while managing access, rights, provenance, and lifecycle | Historical sensor data, machinery records, imagery, FMIS records, advisory records | Data catalogues, metadata repositories, interoperable storage structures | Ownership rules, consent, retention, access rights, benefit-sharing, auditability | Provides governed data assets for analytics and reporting | Trusted records, traceability, reusable farm-data histories | Farmers, cooperatives, platform providers, policymakers | Unclear data rights, weak transparency, fragmented governance |
Security, privacy, and access-control layer | Protects platform services, users, and data assets | User accounts, device identities, farm records, API requests, analytics outputs | Identity management across systems, role-based access, secure API integration | Authentication, authorisation, encryption, privacy safeguards, incident monitoring | Maintains trusted analytical access and protects sensitive inputs | Secure decision services, controlled data sharing, privacy-aware reporting | Farmers, platform providers, advisors, data stewards | Cybersecurity threats, weak credentials, excessive data exposure |
Analytics and AI layer | Produces descriptive, predictive, and prescriptive insights | Cleaned sensor data, weather data, soil data, imagery, machinery records, FMIS records | Access to standardised, contextualised, quality-checked datasets | Model governance, traceability, responsible data use, bias monitoring | Supports crop monitoring, risk prediction, input planning, forecasting, anomaly detection | Predictions, risk scores, recommendations, scenarios, alerts | Researchers, advisors, platform developers, farmers | Poor data quality, opaque models, weak validation, context mismatch |
Decision-support and visualisation layer | Translates analytics into user-facing outputs | Analytics outputs, advisory interpretation, maps, farm records, thresholds | Consistent representation of maps, alerts, recommendations, uncertainty, and context | Explainability, user permissions, accountability for recommendations | Converts model results into actionable decision formats | Dashboards, alerts, prescription suggestions, scouting priorities, management scenarios | Farmers, advisors, cooperatives, service providers | Information overload, unclear uncertainty, low usability |
Farm-management workflow layer | Embeds platform outputs into operational routines | Crop plans, field tasks, machinery operations, advisory schedules, compliance records | Workflow mapping between FMIS, machinery systems, advisory tools, and platform services | Responsibility for decisions, record integrity, transparent task histories | Uses analytics within planning, execution, review, and adaptation cycles | Updated plans, task records, input decisions, advisory actions | Farmers, farm managers, advisors, operators | Misalignment with real farm routines, duplicate data entry, low adoption |
User and stakeholder interface layer | Provides role-specific access and collaboration | Dashboards, advisory portals, mobile interfaces, reports, permissions | Interface consistency, role-based views, cross-platform access | Transparency, consent management, stakeholder accountability | Supports interpretation, communication, and collaborative decision-making | Farmer views, advisor views, cooperative reports, policy-relevant summaries | Farmers, advisors, cooperatives, policymakers, technology providers | Poor interface design, unclear roles, limited trust |
Monitoring, feedback, and learning layer | Tracks platform performance, data quality, decisions, and outcomes | User feedback, field outcomes, system logs, incident reports, model outputs | Feedback-loop integration across data repositories, models, and workflows | Audit trails, accountability, correction rights, incident response | Supports model refinement, quality improvement, and adaptive management | Learning loops, revised recommendations, improved data-quality signals | Farmers, advisors, developers, researchers, governance bodies | Feedback fatigue, weak outcome attribution, insufficient monitoring capacity |
Figure 1 illustrates the proposed interoperable reference architecture for smart farming platforms, showing how data move from field-level systems through interoperability and governance layers into analytics, decision support, and farm-management workflows.
Figure 1. Interoperable Reference Architecture for Smart Farming Platforms. The figure presents a layered architecture linking field-level data sources, connectivity, data ingestion, APIs, semantic interoperability, data governance, analytics, decision support, and farm-management workflows. It shows how sensors, machinery, remote sensing systems, farm-management information systems, and advisory records can be integrated through modular and interoperable platform layers.
Alt-text description: A layered smart farming platform architecture diagram showing sensors, machinery, remote sensing, weather systems, soil data, and farm-management systems feeding into connectivity and data ingestion layers. These connect to API, metadata, semantic interoperability, governance, security, analytics, decision-support, dashboard, and farm workflow layers, with feedback loops from farm decisions back to field systems.
For platform developers, the proposed architecture highlights the need to design smart farming systems as modular integration environments rather than closed applications. API gateways, ingestion services, semantic mappings, storage repositories, governance services, analytics modules, and workflow interfaces should be designed with clear responsibilities and adaptable interfaces. The architecture can help developers connect API-mediated integration, interoperability architecture, FMIS reference architecture, data-management services, and analytics-platform functions without collapsing these functions into a single undifferentiated platform component [12].
For machinery manufacturers, FMIS providers, sensor companies, advisors, cooperatives, and farmers, the architecture clarifies where collaboration is required. Machinery providers must support interpretable operational records, FMIS providers must connect records and workflows, advisors must translate analytics into context-sensitive recommendations, and cooperatives or data stewards may help coordinate governance arrangements. Data ownership, trust, transparency, benefit sharing, security, and privacy should be treated as practical design responsibilities because they shape whether users can legitimately and confidently participate in platform-based data exchange [20-23].
Future research should empirically examine how the proposed architecture performs across farm types, production systems, platform ecosystems, and governance arrangements. Important research needs include cross-platform interoperability testing, API governance models, semantic standards for agricultural operations, farmer-centred interface design, edge-cloud coordination, analytics explainability, cybersecurity monitoring, data-quality assessment, and decision-workflow integration. Decision-support research, responsible AI scholarship, platform-selection research, digital-platform studies, digital twin research, and edge-cloud platform work all suggest that future studies should evaluate not only technical integration but also usability, accountability, adaptability, and the fit between platform outputs and farm decisions [18-19, 27-30].
This article proposed an interoperable reference architecture for smart farming platforms that connects field-level data sources, machinery systems, farm-management information systems, APIs, data standards, semantic interoperability, governance, analytics, decision support, and farm workflows. The central argument is that smart farming platform integration requires more than data transfer or dashboard aggregation: it depends on layered interoperability, contextual metadata, semantic alignment, secure and transparent governance, modular analytics, user-centred decision support, and feedback mechanisms that connect decisions back to farm realities. The architecture offers a structured design logic for researchers, developers, machinery manufacturers, FMIS providers, advisors, cooperatives, farmers, and policymakers while recognising that successful implementation depends on data quality, governance capacity, usability, institutional support, and adaptation to local farm contexts.
None
None
None
None
Open Access The author(s) retain copyright. This article is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. It may be shared and adapted for non-commercial purposes with appropriate attribution, an indication of changes, and distribution of adaptations under the same license. Third-party material may be subject to separate terms identified in its credit line. View the license at https://creativecommons.org/licenses/by-nc-sa/4.0/.
Agro Intelligence Research Press
