[New Model]: Shopfloor Information Model

[wehrstedt-jan]

Model Description

The shopfloor information results contains the forecasting information exchanged between the Modular Production and a second party (customer, logistical etc.).
The forecasting information gives an overview about the current processing state of a product and the estimated production date.
This information will be exchanged between the partners either on request, cyclic with a fixed cycle or on notification, if a forecast is changing.

Relevant Standards

Example Data

Request

SMC	Property	mand./opt.	Semantic ID	Remark
	CX_PartnerID	mandatory	string	could be the same as BPN
	CustomerID	mandatory	string	internal customer ID
	OrderID	mandatory	string
	CommunicationMode	mandatory	enum (synchronous, cyclic, notification)
	Interval	opt	TimeValue [enumTimeUnits, uint ]	required for "cyclic" mode
	Deviation	opt	TimeValue [enumTimeUnits, uint ]	if not defined, a default value willl be used. Depending on the data provider actual deviation can be larger, as a lower bound is given by the data provider
	Precision	opt	TimeValue [enumTimeUnits, uint ]	if not defined, a default value willl be used. Depending on the data provider actual deviation can be larger, as a lower bound is given by the data provider

Response

SMC	Property	mand./opt.	Semantic ID	Remark
header	RequestID	mandatory
	CommunicationMode	mandatory	enum (synchronous, cyclic, notification)
body	ListOfForecastItems	mandatory	List of ForecastItems	list containing all order items
	ForecastItem*
	ProductionForecast	mandatory	datetime	Date of Production
	ProductionStatus	mandatory	enum(orderReceived, orderPlanned, orderInProduction, orderCompleted, orderPostponed, orderCancelled)
	ForecastDate	mandatory	datetime	Date of forecast calculation
	ForecastCertainty	mandatory	Certainty for the forecast date 0,0 .. 0,33 / 0.34 .. 0,6 / …
	Reason4Delay	optional	enum(maschineFailure, supplyProblems)	not every factory will provide too many information
	IterationNo	optional	int	this parameter is only required in the case of the notification mode. It continiously counts the number of updates to gurantee that the notifications are in the correct order.

MS1 Criteria

• The proposed aspect model does not exist already
• The proposed aspect model does not extend an existing aspect but introduces completely new functionality
• The proposal references a Catena-X use case
• Relevant standards are mentioned/linked
• A first draft of the data structure is provided in an example

[wehrstedt-jan]

modeling_team

[bs-jokri]

possible overlap: #154

[bs-jokri]

Notification Header, there is already a standard header under development
#128

[bs-jokri]

BPNS is used as standard

[arnoweiss]

Is this still open now that the PR has been closed without being merged?

[bs-jokri]

ticket replaced by two new tickets, which track the development of both models separately