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

area

Description of an area

Component

Description of a component

Customer

Description of the customer

Device

Description of a Feedmixer wagon

Group

Description of an animal group

Ingredient

description of an ingredient

Nutrients

Current description of the nutrients

Recipe

Current description of a recipe (Recipe)

AfterLoadingLastIngredient

Configuration of the mixing behavior after adding the last ingredient

Masterdata

The master data can be synchronized via this object.

MasterdataResponse

Processing status of the transferred master data

PlannedLoadListWithDependencies

Configuration of a planned load list.

PlannedLoadListWithDependenciesResponse

Processing status of the transferring load list

PlannedLoadList

Configuration of a planned load list with all the necessary references.

PlannedLoadListGroup

Configuration of a group for a planned load list.

PlannedLoadListResponse

Processing status of the transmitted load list

CompleteLoadListWithDependencies

Description of the actual state of a load list.

CompleteLoadListWithDependenciesResponse

Processing status of the transferred actual status for a load list.

CompleteLoadList

Description of the actual state of a load list.

CompleteLoadListIngredient

Completed filling process of an ingredient

CompleteLoadListGroup

Documentation of a group feed for a planned load list.

CompleteLoadListWithDependenciesResponse

Processing status of the transferred actual status for a load list.

RefusalWithDependencies

Documentation of a food refusal including necessary master data

RefusalWithDependenciesResponse

Processing status of the transmitted feed refusal.

Refusal

refusal of food

RefusalResponse

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: Sync Masterdata

Scenario Flow: Synchronization of master data

Scenario Flow: PlannedLoadList

Scenario Flow: Exchange of a load list

Scenario Flow: PlannedLoadListWithDependencies

Scenario Flow: Exchange of a load list with all necessary master data

Scenario Flow: CompleteLoadList

Scenario Flow: Exchange of a completed load list

Scenario Flow: CompleteLoadListWithDependencies

Scenario Flow: Exchange of a completed feeding list with all necessary master data

Scenario Flow: Refusal

Scenario Flow: Exchange of a food refusal

Scenario Flow: RefusalWithDependencies

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 PlannedLoadList, can be transferred with all necessary (referenced) master data or only with a reference.

The master data can be synchronized via the MasterData object; this procedure is described via the scenario flow (Sync MasterData).

After synchronization of the master data, the objects can be used with only one reference to the master data, e.g. PlannedLoadList or CompleteLoadList.

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.