Feedmixer Solution Guide
The use of the available scenario flows in the context of Feedmixer data exchange is described below. At ISO 5231 (EFDI) you can select the available scenario flows and receive a visual representation for each scenario flow, including the message definitions in Protocol Buffers (Protobuf) format for serializing the data.
The following points are covered in this section:
-
What is Protobuf?
-
Compiling the Feedmixer Protocol Buffers Schema
-
Description of the Feedmixer objects
-
Description of the scenario flows
-
Example use cases
What is Protobuf?
Protocol Buffers (Protobuf) is a format developed by Google for serializing data. It stores structured data efficiently and compactly in binary form, enabling faster transmission over network connections. Protobuf supports a wide range of selected programming languages and is platform-independent, which means that programs written using this format can be easily ported to other platforms.
The language-independent syntax enables programs written in different programming languages to communicate reliably with each other.
In addition, the Protobuf format offers several advantages over other formats such as XML or JSON. Since the structured data is stored in binary format, it is much smaller than text-based formats such as XML or JSON, which means it can be transferred faster over networks.
Supported languages include the following:
-
C#
-
C++
-
Java
-
Python
Compile the Feedmixer Protocol Buffers schema
The Feedmixer data structures are defined in .proto-
files, you can generate the classes needed to read and write the protobuf messages. To do this, use the protocol buffers compiler (protoc) on the configuration file.
If the compiler is not yet installed, simply download the latest version from the official GitHub repository. Unpack the ZIP file at the desired location and then start the compiler by double-clicking (located in the "bin"
folder).
Make sure you download the right edition of the Protobuf compiler: Protoc is available for 32- or 64-bit architectures (Windows, Linux or macOS). |
Finally, specify
-
the source directory in which the code of your program is located (here placeholder
"SRC_DIR"
), -
the destination directory in which the generated code is to be saved (here placeholder
"DST_DIR"
) and the path to the .proto files. -
To generate Java classes, for example, we also use the option
--java_out
(similar options are also available for the other supported languages). The complete command for compilation is as follows:protoc -I=$SRC_DIR --java_out=$DST_DIR $SRC_DIR/*.proto
Google offers a more detailed Protobuf Java tutorial, which also explains message transmission via protocol buffers (read/write), in the "Developers" section, the search engine giant’s in-house project area for developers. Alternatively, you can also access instructions for the other supported languages such as C++, Go or Python. |
Description of the Feedmixer objects
Overview of Feedmixer objects
Description of an area |
|
Description of a component |
|
Description of the customer |
|
Description of a Feedmixer wagon |
|
Description of an animal group |
|
description of an ingredient |
|
Current description of the nutrients |
|
Current description of a recipe |
|
Configuration of the mixing behavior after adding the last ingredient |
|
The master data can be synchronized via this object. |
|
Processing status of the transferred master data |
|
Configuration of a planned load list. |
|
Processing status of the transferring load list |
|
Configuration of a planned load list with all the necessary references. |
|
Configuration of a group for a planned load list. |
|
Processing status of the transmitted load list |
|
Description of the actual state of a load list. |
|
Processing status of the transferred actual status for a load list. |
|
Description of the actual state of a load list. |
|
Completed filling process of an ingredient |
|
Documentation of a group feed for a planned load list. |
|
Processing status of the transferred actual status for a load list. |
|
Documentation of a food refusal including necessary master data |
|
Processing status of the transmitted feed refusal. |
|
refusal of food |
|
Processing status of the transmitted feed refusal. |
Most objects contain an UUID
which uniquely refers to an ID in the software system used. In most cases, the object is also described by a (string)
name.
// Universal Unique Identifier (UUID)
// A UUID () is a 128-bit value used to uniquely identify an object or entity
// on the internet. Depending on the specific mechanisms used, a UUID is either
// guaranteed to be different or is, at least, extremely likely to be different
// from any other UUID generated.
// The UUID relies on a combination of components to ensure uniqueness.
// UUIDs are constructed in a sequence of digits equal to 128 bits.
// The ID is in hexadecimal digits, meaning it uses the numbers 0 through 9 and
// letters A through F. The hexadecimal digits are grouped as 32 hexadecimal
// characters with four hyphens: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXXXX.
// The number of characters per hyphen is 8-4-4-4-12.
// e.g.
// 111e8400-a56c-11d4-a616-8966554478aa
//
message UUID {
string value = 1;
}
Master data
Areas
Description of an area (Area)
, this can be a loading point (AreaType = A_LOADING_POINT)
, here feed mints are loaded.
A barn (AreaType = A_BARN)
, in which the mixed feed is unloaded, is also described via the object.
The areas have a reference to a customer (Customer)
, this is done via customer_id_ref
.
// Area - ARS
message Area {
enum AreaType {
A_LOADING_POINT = 0;
A_BARN = 1;
A_OTHER = 2;
}
UUID area_external_id = 1; /// Uniquely references for the area in the sofware system used
string area_name = 2; /// Name of the area
AreaType area_type = 3; /// Type of the area (LoadingPoint, Barn, other)
UUID customer_id_ref = 4; /// Internal reference
repeated google.protobuf.Any extension = 2048;
}
Components
Description of a component (Component)
The component type is described via the ComponentType
.
The nutrients are specified via the object (Nutrients)
.
The reference to a loading location (Area)
is configured via the area_id_ref
.
// Component - CMP
message Component {
enum ComponentType {
A_ROUGHAGE = 0;
A_BY_PRODUCT = 1;
A_CONCENTRATE = 2;
A_FRESH_GRASS = 3;
A_MINERAL = 4;
A_MEDICATION = 5;
A_OTHER = 6;
}
UUID component_external_id = 1; /// Uniquely references for the component in the sofware system used
string component_name = 2; /// Name of the component
ComponentType component_type = 3; /// Type of the component
Nutrients nutrients = 4; /// Included Nutrients object
UUID area_id_ref = 5; /// Internal reference
repeated google.protobuf.Any extension = 2048;
}
Customer
Description of the customer (Customer)
.
// Customer - CTR
message Customer {
UUID customer_external_id = 1; /// Uniquely references for the customer in the sofware system used
string customer_name = 2; /// Name of the customer
repeated google.protobuf.Any extension = 2048;
}
Feedmixer wagon
Description of a Feedmixer wagon (Device)
.
In addition to the name (device_name)
of the serial number (device_serial_number)
, the load capacity (device_capacity)
is described in the unit kg.
The possible loading and unloading points for this Feedmixer wagon are specified via a white list (repeated UID area_id_ref)
.
// Device - DVC
message Device {
UUID device_external_id = 1; /// Uniquely references for the device in the sofware system used
string device_serial_number = 2; /// Serial number of the device assigned by the manufacturer
string device_name = 3; /// Name of the device
uint64 device_capacity = 4; /// Total KG capcaity of the mixer (treshold of overload). Unit: *kg*
repeated UUID area_id_ref = 5; /// White-List means, list of areas that can be accessed
repeated google.protobuf.Any extension = 2048;
}
Animal group
Description of an animal (Group)
.
The animal group-type is described via the GroupType
.
The number of animals in this animal group is specified via the parameter: (group_head_count )
in the unit piece.
The relative percentage for adjusting the feed quantity (default value 100%) is determined via the factor (group_feeding_factor)
in the unit %.
The length of the feeding rack (in m) of this animal group is described by the parameter group_feeding_rack_length
.
The reference to the area of the animal group (Area)
is made via the area_id_ref
.
// Group - GRP
message Group {
enum GroupType {
A_MILKING = 0;
A_DRY = 1;
A_BULLS = 2;
A_OTHER = 3;
}
UUID group_external_id = 1; /// Uniquely references for the group in the sofware system used
string group_name = 2; /// Name of the group
GroupType group_type = 3; /// Type of the group (milking, dry, bulls, other)
uint32 group_head_count = 4; /// Total number of annimals for this group. : piece
uint32 group_feeding_factor = 5; /// Relative percentage used to adjust feed amount for a group. (default 100%). %
uint32 group_feeding_rack_length = 6; /// Length of feeding rack of the specific group. m
UUID area_id_ref = 7; /// Internal reference
repeated google.protobuf.Any extension = 2048;
}
Ingredients
Description of an ingredient (Ingredient)
and its application.
The start mode type is described via the StartMode
.
The quantity per animal is specified via the parameter ingredient_quantity
in the kg/head.
The loading sequence in which this ingredient is to be filled is described by the value ingredient_order
.
The mixing process for this ingredient can be configured using the following values:
-
ingredient_mix_time
in the seconds -
ingredient_mix_speed
in the unit RPM/min -
ingredient_mix_rotations
in the unit RPM
The start time of the mixing process can be controlled via the parameter ingredient_start_percentage
(unit %), i.e. the mixing process can start when X percent has been added.
// Ingredient - ING
message Ingredient {
enum StartMode {
A_AUTO = 0;
A_MANUAL = 1;
A_OTHER = 2;
}
UUID ingredient_external_id = 1; /// UUID of the ingredient used in the recipe
UUID component_id_ref = 2; /// Internal reference
uint32 ingredient_quantity = 3; /// Quantity (kg/head) actual load. Unit: kg/head
uint32 ingredient_order = 4; /// Loading position/ sequence in load list
StartMode start_mode = 5; /// Start mode (auto, maunual, other)
uint32 ingredient_mix_time = 6; /// Total mix time expected during or after each ingredient. Unit sec
uint32 ingredient_mix_speed = 7; /// Mix speed expected for each ingredient. Unit RPM/min
uint32 ingredient_mix_rotations = 8; /// Mix rotations expected for each ingredient. Unit RPM
uint32 ingredient_start_percentage = 9; /// Starting percentage of the total weight of the current ingredient to start the mixer. Unit %
repeated google.protobuf.Any extension = 2048;
}
Nutrients
Current description of the nutrients (Nutrients)
.
// Nutrients - NUT
message Nutrients {
double dry_matter = 1; /// Expected dry matter percentage. Unit %
repeated google.protobuf.Any extension = 2048;
}
Recipes
Current description of a recipe (Recipe)
. The parameter recipe_density
specifies the density per kg/m³.
The version of the recipe is made visible via recipe_revision
.
The recipe_premix
indicator is used to determine whether the recipe is intended for premixing.
The ingredient list and its filling sequence is configured via repeated Ingredient ingredient_ref
.
The mixing behavior after the last ingredient has been added is described via the object: after_loading_last_ingredient
.
// Recipe - RCP
message Recipe {
UUID recipe_external_id = 1; /// Uniquely references for the recipe in the sofware system used
string recipe_name = 2; /// Name of the recipe
uint32 recipe_density = 3; /// Density of specific recipe. Unit kg/m³
uint32 recipe_revision = 4; /// Progressive ID to identify the different changes applied to the recipe
bool recipe_premix = 5; /// Flag to tell if the recipe is for a premix
repeated Ingredient ingredient_ref = 6; /// Included Ingredients array (ING)
AfterLoadingLastIngredient after_loading_last_ingredient = 7; /// Included After loading ingredient (ALI)
repeated google.protobuf.Any extension = 2048;
}
Mixing behavior after adding the last ingredient.
Configuration of the mixing behavior after adding the last ingredient (AfterLoadingLastIngredient)
. The start mode type is described via the StartMode
.
The final mixing process can be configured using the following values:
-
afterloadinglastingredient_mix_time
in the unit seconds -
afterloadinglastingredient_mix_speed
in the unit RPM/min -
afterloadinglastingredient_mix_rotations
in the unit RPM
// AfterLoadingLastIngredient - ALI
message AfterLoadingLastIngredient {
enum StartMode {
A_AUTO = 0;
A_MANUAL = 1;
A_OTHER = 2;
}
StartMode start_mode = 1;
uint32 afterloadinglastingredient_mix_time = 2; /// Total mix time expected during or after the last ingredient. Unit sec
uint32 afterloadinglastingredient_mix_speed = 3; /// Mix speed expected for the last ingredient. Unit RPM/min
uint32 afterloadinglastingredient_mix_rotations = 4; /// Mix rotations expected for the last ingredient. Unit RPM
repeated google.protobuf.Any extension = 2048;
}
Master data, synchronization
The master data can be synchronized via this object.
This procedure is described via the scenario flow (Sync MasterData)
.
// MasterData for synchronization (SYNC verb).
message MasterData {
repeated Area area = 1;
repeated Component component = 2;
repeated Customer customer = 3;
repeated Device device = 4;
repeated Group group = 5;
repeated Ingredient ingredient = 6;
repeated Recipe recipe = 7;
repeated Worker worker = 8;
repeated google.protobuf.Any extension = 2048;
}
Response object for transferred MasterData
The MasterDataResponse
object is used to return the processing status of the transferred master data (MasterData)
via the response_code
.
message MasterDataResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_MASTERDATA = 2; /// Given MasterData cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the MasterData cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Transaction data
Load list including necessary master data
Configuration of a planned load list.
This object also contains all the necessary (referenced) master data. |
// PlannedLoadListWithDependencies for synchronization
message PlannedLoadListWithDependencies {
PlannedLoadList plannedLoadList = 1;
repeated Area area = 2;
repeated Component component = 3;
repeated Customer customer = 4;
repeated Device device = 5;
repeated Group group = 6;
repeated Ingredient ingredient = 7;
repeated Nutrients nutrients = 8;
repeated Recipe recipe = 9;
repeated Worker worker = 10;
repeated google.protobuf.Any extension = 2048;
}
Response object for a transferring load list
The PlannedLoadListWithDependenciesResponse
object is used to return the processing status of a transferred PlannedLoadListWithDependencies
via the response_code
.
message PlannedLoadListWithDependenciesResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_PLANNEDLOADLISTWITHDEPENDENCIES = 2; /// Given PlannedLoadListWithDependencies cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the PlannedLoadListWithDependencies cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Load list
Configuration of a planned load list with all the necessary references.
This object only contains the references to the necessary master data |
The plannedloadlist_id
is the ID of the planned load list. The type of the load list is described via the PlannedLoadListType
.
The reference to the recipe to be used is created via the UID recipe_id_ref
. The expected start date is specified (in ISO 8601 format) via the plannedloadlist_starttime
parameter.
The animal groups to be fed are configured via list plannedloadlist_group
of object type PlannedLoadListGroup
.
// PlannedLoadList - PLL
message PlannedLoadList {
enum PlannedLoadListType {
B_PLANNED = 0;
B_ADHOC = 1;
B_OTHER = 2;
}
UUID plannedloadlist_id = 1; /// Uniquely references for the planned load list in the sofware system used
PlannedLoadListType plannedloadlist_type = 2; /// Type of the planned load list (planned, adhoc, other)
UUID recipe_id_ref = 3; /// Internal reference
string plannedloadlist_starttime = 4; /// Expected start time. Datetime in ISO 8601 representation
repeated PlannedLoadListGroup plannedloadlist_group = 5; /// Included PlannedLoadListGroup object
repeated google.protobuf.Any extension = 2048;
}
Group list for a load list
Configuration of a group for a planned load list.
The reference to a group (Group)
is made via the group_id_ref
.
The expected end load date is specified (in ISO 8601 format) via the parameter plannedloadlistgroup_discharge_time
.
The feeding order of this group is specified via the parameter plannedloadlistgroup_order
in the unit piece.
The plannedloadlistgroup_feeding_factor
describes the relative percentage for adjusting the feed quantity of the group. (default value 100%). Unit %.
// PlannedLoadListGroup - internal object
message PlannedLoadListGroup {
UUID group_id_ref = 1;
string plannedloadlistgroup_discharge_time = 2; /// Expected start time. Datetime in ISO 8601 representation
int32 plannedloadlistgroup_order = 3; /// Order in the list of groups to be fed. Unit piece
int32 plannedloadlistgroup_feeding_factor = 4; /// Relative percentage used to adjust feed amount for a group. (default 100%). Unit %
repeated google.protobuf.Any extension = 2048;
}
Response object for a transmitted load list
The PlannedLoadListResponse
object is used to return the processing status of a transmitted PlannedLoadList
via the response_code
.
message PlannedLoadListResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_PLANNEDLOADLIST = 2; /// Given PlannedLoadList cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the PlannedLoadList cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Completed load list including necessary master data
The CompleteLoadListWithDependencies
object is used to describe the actual status of a load list.
This object also contains all the necessary (referenced) master data. |
// CompleteLoadListWithDependencies for synchronization.
message CompleteLoadListWithDependencies {
CompleteLoadList completeLoadList = 1;
repeated Area area = 2;
repeated Component component = 3;
repeated Customer customer = 4;
repeated Device device = 5;
repeated Group group = 6;
repeated Ingredient ingredient = 7;
repeated Nutrients nutrients = 8;
repeated Recipe recipe = 9;
repeated Worker worker = 10;
repeated google.protobuf.Any extension = 2048;
}
Response object for a transmitted completed feeding list
The CompleteLoadListWithDependenciesResponse
object is used to return the processing status for a transmitted CompleteLoadListWithDependencies
via the response_code
.
message CompleteLoadListWithDependenciesResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_COMPLETELOADLISTWITHDEPENDENCIES = 2; /// Given CompleteLoadListWithDependencies cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the CompleteLoadListWithDependencies cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Completed load list
The CompleteLoadList
object is used to describe the actual status of a PlannedLoadList
.
The Feedmixer used is referenced via the parameter device_id_ref
, the same applies to the employee via worker_id_ref
.
The underlying load list is referenced via plannedloadlist_id_ref
.
The start and end time is specified via completeloadlist_start_time
and completeloadlist_end_time
respectively.
The planned feeding quantity in the unit kg is returned via the parameter completeloadlist_totalTheoreticalQty
and the quantity actually fed (kg) via the parameter completeloadlist_totalQty
.
The actual filling and mixing process for each ingredient is described in the completeLoadListIngredient
list of object type CompleteLoadListIngredient
.
The animal groups that were fed with this load are configured via the completeLoadListGroup
list of the CompleteLoadListGroup
object type.
// CompleteLoadList - CLL
message CompleteLoadList {
UUID completeloadlist_external_id = 1; /// ID of the CompleteLoadList
UUID device_id_ref = 2; /// Internal reference
UUID worker_id_ref = 3; /// Internal reference
UUID plannedloadlist_id_ref = 4; /// Internal reference
string completeloadlist_start_time = 5; /// Start time the load is executed. Datetime in ISO 8601 representation
string completeloadlist_end_time = 6; /// End time the load is executed. Datetime in ISO 8601 representation
double completeloadlist_totalTheoreticalQty = 7; /// Total programmed quantity. Unit kg
double completeloadlist_totalQty = 8; /// Total real quantity. Unit kg
repeated CompleteLoadListIngredient completeLoadListIngredient = 9; /// Included CompleteLoadListIngredient object
repeated CompleteLoadListGroup completeLoadListGroup = 10; /// Included CompleteLoadListGroup object
repeated google.protobuf.Any extension = 2048;
}
Completed filling process of an ingredient
The underlying ingredient is referenced via ingredient_id_ref
.
The start and end time of the filling is documented via completeloadlistingredient_start_time
and completeloadlistingredient_end_time
respectively.
The loading order is described via the parameter completeloadlistingredient_order
in the unit piece.
The completeloadlistingredient_realQty
specifies the actual quantity in kg.
The actual mixing time and the mixing speed are documented via completeloadlistingredient_real_mix_time
and completeloadlistingredient_real_mix_speed
.
// CompleteLoadListIngredient - internal object
message CompleteLoadListIngredient {
UUID ingredient_id_ref = 1;
string completeloadlistingredient_start_time = 2; /// Start time of the load of each specific ingrdient. Datetime in ISO 8601 representation
string completeloadlistingredient_end_time = 3; /// End time of the load of each specific ingrdient.Datetime in ISO 8601 representation
int32 completeloadlistingredient_order = 4; /// Loading position/ sequence in load list. Unit piece
double completeloadlistingredient_realQty = 5; /// Total real quantity. Unit kg
int32 completeloadlistingredient_real_mix_time = 6; /// Total mix time. Unit sec
int32 completeloadlistingredient_real_mix_speed = 7; /// Total mix rotations. Unit rpm
repeated google.protobuf.Any extension = 2048;
}
Completed group list for a loading list
Documentation of a group feed for a planned loading list.
The reference to a group (Group)
is made via the group_id_ref
.
The actual start and end load date is documented (in ISO 8601 format) via completeloadlistgroup_start_time
and completeloadlistgroup_end_time
.
The completeloadlistgroup_theoreticalQty
specifies the planned quantity in kg, the parameter completeloadlistgroup_realQty
describes the actual quantity in the unit kg.
// CompleteLoadListGroup - internal object
message CompleteLoadListGroup {
UUID group_id_ref = 1;
string completeloadlistgroup_start_time = 2; /// Start time the load is executed. Datetime in ISO 8601 representation
string completeloadlistgroup_end_time = 3; /// End time. Datetime in ISO 8601 representation
double completeloadlistgroup_theoreticalQty = 4; /// Total programmed quantity. Unit kg
int32 completeloadlistgroup_realQty = 5; /// Total real quantity. Unit kg
repeated google.protobuf.Any extension = 2048;
}
Response object for a completed load list
The CompleteLoadListResponse
object is used to return the processing status for a transmitted CompleteLoadList
via the response_code
.
message CompleteLoadListResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_COMPLETELOADLIST = 2; /// Given CompleteLoadList cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the CompleteLoadList cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Documentation of a feed refusal including necessary master data
Documentation of a feed refusal.
This object also contains all the necessary (referenced) master data. |
// RefusalWithDependencies for synchronization (SYNC verb).
message RefusalWithDependencies {
Refusal refusal = 1;
repeated Group group = 2;
repeated google.protobuf.Any extension = 2048;
}
Response object for a transmitted refusal to feed
The RefusalWithDependenciesResponse
object is used to return the processing status for a transmitted RefusalWithDependencies
via the response_code
.
message RefusalWithDependenciesResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_REFUSALWITHDENPENDENCIES = 2; /// Given RefusalWithDependencies cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the RefusalWithDependencies cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Documentation of a food refusal
The group for which the refusal is documented is referenced via the group_id_ref
parameter.
The documentation time is described in ISO 8601 format via refusal_time
.
The quantity in kg is specified via refusal_totalQty
.
// Refusal - RFL
message Refusal {
UUID refusal_external_id = 1; /// Uniquely references for the refusal in the sofware system used
UUID group_id_ref = 2; /// Internal reference
string refusal_time = 3; /// Time of collection. Datetime in ISO 8601 representation
double refusal_totalQty = 4; /// Quantity (kg/lb/etc..) of refused collected. Unit kg
repeated google.protobuf.Any extension = 2048;
}
Response object for a transmitted feed refusal
The RefusalResponse
object is used to return the processing status for a transmitted Refusal
via the response_code
.
message RefusalResponse {
enum ResponseCode {
OK = 0; /// No error occured
CANNOT_PROCESS_REFUSAL = 2; /// Given Refusal cannot be processed
}
ResponseCode response_code = 1; /// Response code with processing information
string response_text = 2; /// Response text with human-readable information on why the Refusal cannot be processed
repeated google.protobuf.Any extension = 2048;
}
Description of the ISO 5231 (EFDI) standard
ISO 5231 "Extended Farm Management Information Systems Data Interface" (EFDI) describes a standardized data model and a communication interface, which aims to efficiently exchange information between agricultural management systems (herd management, feed management or farm management information systems) and other systems such as machines, sensors or external services. The concept of scenario flows within the standard provides a framework for modelling typical workflows in a structured way and standardizing their data flows.
General description of the scenario flows
The scenario flows are a methodical representation of use cases and workflows. They are used to harmonize and document the exchange of information between different actors and systems. This is done by defining standardized data structures and processes. The most important features of the concept are
-
Objective orientation Each scenario flow represents a specific work process or use case, e.g. the planning and implementation of feeding, fertilization, harvesting or the monitoring of livestock.
-
Actors and systems The flows take into account the various actors (e.g. farmer, consultant, service provider) and the systems involved (e.g. herd feed management systems, machine control systems, sensors).
-
Standardized data structures The standard specifies which data formats and protocols are used to ensure that different systems can communicate with each other.
-
Modeling of workflows Processes are modeled in logical steps that map the flow of information from the start (e.g. planning) through execution to documentation and evaluation.
-
Interoperability and scalability The standardized definition of data and processes allows different systems to work together seamlessly, regardless of manufacturer or software environment. This promotes interoperability and scalability for small and large companies.
-
Examples of scenario flows
-
Planning process: Creation of a ration plan in the herd management system, transmission of the data to the Feedmixer, feedback of the measures carried out.
-
Real-time monitoring: Collection of sensor data (e.g. weather station), evaluation in real time and automated adjustment of measures.
-
Documentation: Automatic recording of machine data during field work and integration into legal documentation requirements.
-
Integration and extension Scenario Flows can be adapted to specific needs and technologies while maintaining compatibility with other standards and systems.
Advantages of scenario flows
-
Increased efficiency: Automated information exchange reduces manual input and errors.
-
Transparency: Clearly defined processes and data flows promote better traceability of workflows.
-
Flexibility: Ability to integrate new technologies and use cases.
-
Cost reduction: Standardized interfaces reduce development and integration costs for manufacturers and companies.
Possible scenarios Flows in the Feedmixer context
Scenario Flow: Synchronization of master data |
|
Scenario Flow: Exchange of a load list |
|
Scenario Flow: Exchange of a load list with all necessary master data |
|
Scenario Flow: Exchange of a completed load list |
|
Scenario Flow: Exchange of a completed feeding list with all necessary master data |
|
Scenario Flow: Exchange of a food refusal |
|
Scenario Flow: Exchange of a feed refusal with all necessary master data |
These scenarios involve creating, managing and exchanging a list of planned loads for a Feedmixer wagon between different systems. This typically involves the following steps:
-
Planning of feed rations: A herd or feed management system creates a detailed feed ration based on the nutritional needs of the animals and available feed resources.
-
Creation of the loading list: Based on the planned feed ration, a specific loading list is created for the Feedmixer wagon, specifying the exact quantities and types of feed to be loaded.
-
Transmission to the Feedmixer: The loading list created is transmitted electronically to the control system of the Feedmixer wagon to control the loading and mixing process.
-
Performing the mixing process: The Feedmixer carries out the mixing process according to the loading list received and ensures that the animals receive the planned feed ration.
-
Reporting and documentation: On completion of the mixing and feeding process, the actual quantities of feed loaded and distributed are reported back to the herd or feed management system to document the feeding data and make it available for future analysis.
-
Feed refusal of an animal group: Feed quantities for an animal group that have been refused can be reported back to the herd or feed management in order to document them and make them available for future analyses.
These scenarios ensure that the entire process of feed planning, mixing and distribution is carried out efficiently and accurately by enabling seamless communication and data integration between herd or feed management systems and Feedmixers.
A special feature is that some of the transaction data, e.g. of a The master data can be synchronized via the After synchronization of the master data, the objects can be used with only one reference to the master data, e.g. |
Scenario Flow: Synchronization of master data
Master data can be exchanged for synchronization via the MasterData
object.
The recipient saves all or the updated master data in its database/file system.
The processing status is transmitted to the sender via the MasterDataResponse
object.
Scenario Flow: Exchange of a load list
This scenario flow describes the data exchange of a PlannedLoadList
, e.g. from a herd management system to a Feedmixer.
The status of the processing is transmitted to the sender via the PlannedLoadListResponse
object.
In the first step, the receiver (Feedmixer) attempts to resolve the references of the required objects via its stored objects.
If this is successful, OK
is used as the ResponseCode
for the PlannedLoadListResponse
and successful processing is acknowledged.
However, if one or more references could not be resolved, CANNOT_PROCESS_PLANNEDLOADLIST
is used as the ResponseCode
for the PlannedLoadListResponse
.
This signals to the sender (herd management system) that necessary master data is missing on the Feedmixer wagon and a synchronization of the master data must be triggered.
See also: Scenario Flow - Synchronization of master data
Scenario Flow: Exchange of a load list with all necessary master data
This scenario flow describes the data exchange of a PlannedLoadListWithDependencies
, e.g. from a herd management system to a Feedmixer.
The status of the processing is transmitted to the sender via the object PlannedLoadListWithDependenciesResponse
.
In the first step, the receiver (Feedmixer) attempts to resolve the references of the necessary objects via its stored objects.
If this is successful, OK
is used as the ResponseCode
for the PlannedLoadListWithDependenciesResponse
, thus confirming successful processing.
However, if one or more references could not be resolved, CANNOT_PROCESS_PLANNEDLOADLISTWITHDEPENDENCIES
is used as the ResponseCode
for the PlannedLoadListWithDependenciesResponse
.
This signals to the sender (herd management system) that the content of the load list is not correct and must be checked/corrected and therefore resent.
Scenario Flow: Exchange of a completed load list
This scenario flow describes the data exchange of a CompleteLoadList
from a Feedmixer to the herd or feed agent system.
The status of the processing is transmitted to the sender via the CompleteLoadListResponse
object.
In the first step, the receiver (herd feed management) attempts to resolve the references of the transmitted objects.
If this is successful, OK
is used as the ResponseCode
in the CompleteLoadListResponse
, thus confirming successful processing.
If, however, one or more references could not be resolved, CANNOT_PROCESS_COMPLETELOADLIST
is used as the ResponseCode
for the CompleteLoadListResponse
.
This signals to the sender (Feedmixer) that necessary master data is missing and a synchronization of the master data must be triggered.
See also: Scenario Flow - Synchronization of master data
Scenario Flow: Exchange of a completed load list with all necessary master data
This scenario flow describes the data exchange of a CompleteLoadListWithDependencies
from a Feedmixer to a herd or feed agent system.
The status of the processing is transmitted to the sender via the CompleteLoadListWithDependenciesResponse
object.
In the first step, the receiver (herd feed management) attempts to resolve the references of the necessary objects via its stored objects.
If this is successful, OK
is used as the ResponseCode
for the CompleteLoadListWithDependenciesResponse
, thus confirming successful processing.
However, if one or more references could not be resolved, CANNOT_PROCESS_COMPLETELOADLISTWITHDEPENDENCIES
is used as the ResponseCode
for the CompleteLoadListWithDependenciesResponse
.
This signals to the sender (Feedmixer) that the content of the completed loading list is not correct. This must be checked and corrected so that it can be resent.
Scenario Flow: Exchange of a feed refusal
This scenario flow describes the data exchange of the Refusal
object from a Feedmixer to a herd or feed management system.
The status of the processing is transmitted to the sender via the RefusalResponse
object.
In the first step, the receiver (herd feed management) attempts to resolve the references of the necessary objects via its stored objects.
If this is successful, OK
is used as the ResponseCode
in the RefusalResponse
, thus acknowledging successful processing.
However, if one or more references could not be resolved, CANNOT_PROCESS_REFUSAL
is used as the ResponseCode
for the RefusalResponse
.
This signals to the sender (Feedmixer) that the feed refusal content is incorrect. This must be checked and corrected so that it can be resent.
Scenario Flow: Exchange of a feed refusal with all necessary master data
This scenario flow describes the data exchange of a RefusalWithDependencies
from a Feedmixer to a herd or feed agent system.
The status of the processing is transmitted to the sender via the RefusalWithDependenciesResponse
object.
In the first step, the receiver (herd feed management) attempts to resolve the references of the necessary objects via its stored objects.
If this is successful, OK
is used as the ResponseCode
in the RefusalWithDependenciesResponse
, thus confirming successful processing.
If, however, one or more references could not be resolved, CANNOT_PROCESS_REFUSALWITHDENPENDENCIES
is used as the ResponseCode
for the RefusalWithDependenciesResponse
.
This signals to the sender (Feedmixer) that the content for feed refusal is not correct. This must be checked and corrected so that it can be resent.