# Introduction to Mission Control

Welcome to an Introduction of Mission Control. This guide is meant to give you an overview of the functionalities Mission Control offers and its role in the Zaikio platform.

# What is Mission Control?

Mission Control is the central data exchange and process monitoring station for the Zaikio platform.

# What does Mission Control do?

Mission control provides an API that allows you to store orders, product specifications (including binary file references), logistics information, and all shop floor specific data (including impositions, tasks, material requirements, production schedules, etc.). Other apps can then use the same API to retrieve that data. Mission Control is based on a persistent database, so other apps can query the data you provide at any time (as opposed to being a mere forwarding architecture). Mission control will also check all incoming data for compliance with our standard data model, as well as plausibility. Thus we ensure that connected apps can trust that all information retrieved from Mission Control is compliant and valid from a logical point of view.

In summary, Mission Control's core functions are:

  • Data exchange between connected apps regarding orders, product specifications, logistics, and all required data for shop floor operations
  • Action triggering by sending events to all connected apps whenever data changes, so that the apps can react
  • Process monitoring and shop floor awareness of equipment (IoT) as well as end users through the API and the UI

# What does Mission Control not do?

Mission Control's core functions are data exchange and progress tracking. As such, it is designed solely as a data repository. Mission Control will not generate data by itself. It will not create orders or product specifications, nor does it know how to find files or generate production schedules. It does, however, provide the required data models and API interfaces for third party apps to create that information. In essence, Mission Control is completely reliant on third party applications and data to make it come to live.

# Dissecting Mission Control – the data parts

Mission Control's data model covers a wide range of topics in order to facilitate an end-to-end process for printers. To make the data model and API more accessible we have divided it into the following components:

# Business

This part covers everything related to the order of printed goods and the business transaction that lies behind it, such as customer information, payment information, invoicing information, etc. The order is loosely coupled to products via its line items, but apart from this we keep the two independent.

Further reading on the Business API coming soon.

# Product Specifications

This part covers everything related to a single printed product (often called job). Since Mission Control's function is that of a data exchange, it doesn't know about product templates, instead it requires a complete product specification for every single job produced. Product specifications cover all information necessary to describe a printed item: product parts including their layout (both boxed and path-based), colours, desired substrates, as well as finishings and their application, raw material requirements and confectioning (packaging during production).

Further reading on the Product Specifications API coming soon.

# Logistics

This part covers how products and other materials are picked, packed and dispatched to their destinations, including carrier and parcel information, manifests, shipping lists and the like. Throughout Mission Control we strictly separate confectioning (applying packaging during the production process, which is part of the product specification) and commissioning (applying packaging after the production process and are thus part of the logistics API). Further reading on the Logistics API coming soon.

# Shopfloor

This part covers how products are made on the shop floor. It provides interfaces and data models to store information regarding tasks, their durations and phases, planned and actual costs, executions and schedules, intermediate products (including their layouts) coming out of tasks and connecting tasks together, thus building a process network, as well as artwork references, and material demands. Further reading on the Shopfloor API coming soon.