Develop content
Linux The development of process recipe management terminal is suitable for projects where "the same equipment needs to switch multiple process recipes". The work is divided around the system, device interface and business program of the target product. It can start from the development of a single module on the existing board, or it can be combined into device software integration.
Recipe modeling
Define parameter types, units, boundaries, versions and applicable devices.
Change management
Develop editing, review, publishing permissions, and recipe version records.
Device delivery
Send parameters in stages by interface, verify write results and read back differences.
Batch traceability
Bind the actual execution recipe to the production batch, and record exceptions and recovery actions.
System composition and business processes
Recipe editing → Verification release → Send readback → Batch binding.
Develop recipe version, parameter verification, controlled delivery, equipment parameter readback, batch association, operation audit and permissions. Clarify the normal status, failure status and recovery entrance for each link, and keep records that can correspond to the same device and task during joint debugging.
Project input
- Dictionary of recipe parameters.
- Device write and readback interface.
- Batch numbering and release process.
- Target board, BSP/kernel, existing programs and dependent versions.
- Delivery source code scope, on-site cooperation and reviewable pass conditions.
Delivery and acceptance
| Delivery object | Acceptance and information |
|---|---|
| Programs and Interfaces | Delivery Linux The agreed application source code, interface adaptation and configuration of the process recipe management terminal; use real equipment to check input, status and output. |
| Business and data | Press "Recipe Edit → Verify Release → Send Readback → Batch Binding" to check the correspondence between data, tasks and execution results, and provide field, status and exception handling instructions. |
| Operation and acceptance | Focus on verifying recipe and batch binding, delivery confirmation, readback differences and recovery strategies; record boards, systems, application versions, samples and test steps. |
| Deployment and maintenance | Deliver build or installation data, log descriptions, version lists and known issues; verify installation, startup and recovery according to the agreed environment. |
Scope and collaboration
The legal range of the recipe is confirmed by the party responsible for the process; the processing when writing some parameters fails must be consistent with the equipment controller.
Hardware modifications, third-party authorized components, cloud systems and on-site implementation are listed separately according to project needs. The interface data and prototypes are confirmed when the project is started, and phased joint debugging is based on the agreed version and business use cases.
FAQ
What to do if the recipe is interrupted halfway through?+
Depending on the device support, confirm after temporary storage, read back item by item, or restore to the confirmed version; the page will display an unfinished status to avoid showing partial success as overall completion.
Linux What information should be provided before starting the development of process recipe management terminal?+
First, the recipe parameter dictionary, device writing and readback interface, batch number and release process are provided, and the target board and system version are supplemented; existing codes and fault records can be used to narrow the scope of changes.
How to determine the acceptance conditions for this project?+
Bind recipes to batches, issue confirmation, read back differences and recovery strategies into reproducible use cases, clarify prototypes, software versions, loads, measurement points and passing conditions, and then accept based on test records.
Testing and verification supporting development
The following tasks can be split according to equipment, interface and sample conditions. The specific output and acceptance methods are confirmed in the project scope.
Test recipe version and change impact checking tools
Development and delivery：Compare version differences and list samples that need to be retested and failure result ranges
Project input：Real authorization data, units/fields, manual baselines, models/formulas, and permissions
Acceptance method：Use known recipe differences to check parameters/thresholds, device binding, approval release readback and retest range, and verify the status after some update failures.
FAQ
Test recipe version and change impact checking tools：What input conditions are required for this task?
Real authorization data, units/fields, manual baselines, models/formulas, and permissions
Test recipe version and change impact checking tools：How to accept this task?
Use known recipe differences to check parameters/thresholds, device binding, approval release readback and retest range, and verify the status after some update failures.
Test recipe version and change impact checking tools：Can I delegate only the instrument interface or test software?
The scope can cover an individual instrument driver, acquisition, process control, data calculation or user-interface module. Complete equipment integration requires separate agreement on mechanical, electrical, method and site responsibilities.
View the Test Assembly and Instrumentation Development Catalog
Online
Phone
WeChat
Top