Submit, Integrate, Test, and Release – SITaR ENOVIA Synchronicity DesignSync Data Manager provides an intuitive built-in workflow called SITaR (Submit, Integrate, Test, and Release). SITaR consists of a set of commands that leverage the power of module-based design in an environment consisting of multiple design modules aggregated together by an integrator into a higher level system. Though individual design blocks (modules) may be contributed by different teams, design at the block level cannot occur in a vacuum. Simulations must include interactions with the other blocks in the design.
SITaR is based on the notion that there are two fundamental “roles” in play in such a design:
a “designer” is someone who is contributing at the block level. An “integrator” is responsible for integrating blocks together into a toplevel design, testing the system, and releasing the stable “baseline” (a system level configuration of blocks) from which all subsequent block level development occurs.
Working within such a flow, a designer would fetch the current stable baseline into a workspace. The block the designer is working on would then be put in an “edit” mode, and design activities proceed. All simulation takes place in the context of the baseline consisting of all the other blocks. The key here is that design work and simulation is NOT done with work-in-process configurations of other blocks, but only in the context of the stable baseline.
When work is complete, the designer “submits” his module for possible integration into a newer baseline. The integrator monitors the submission queue, which could contain submissions for multiple blocks, and is able to build a workspace containing any mixture of submitted blocks. This is the “Integrate” step in SITaR. Regression tests are performed against the newly integrated set of blocks (the “Test” step in SITaR), and if deemed stable by the integrator, can be released as a new stable baseline (the “Release” step in SITaR). Designer workspaces could then be updated, fetching the baseline for all blocks for which editing activity is not occurring.
Thus, ALL design work at the block level is performed in the context of a stable baseline of the rest of the blocks in the design. All this activity is performed using simple and intuitive commands such as “sitr submit,” or “sitr integrate,” alleviating the need to educate the contributing teams in the use of the more fundamental module design command set, or with complicated handoff and tagging schemes.
SITaR commands wrap the underlying module commands such that the power of the module-based DDM architecture is leveraged in the context of this well-defined use model.
