Telestra 4 FAQs
Can I use the Studio Development Workstation as a stand-alone development platform?
The short answer is: "No, the Workstation must be linked to a specific Target platform, before any development is possible".
To expand on this let us review a few T4 fundamentals. A Target platform runs a simulation model utilizing the processing capability of the CPU, and can be configured to operate in an embedded mode, such that the platform powers up, loads, and runs a pre-selected model. In this operating mode, no external platform is needed to operate. This allows optimization of the core software on the Target to the runtime task, which after all, is the intended operating mode for any platform deployed to a training device or simulator. In the typical life of an ASTi system, we might see the system used in development mode for perhaps 6 months or so, followed by 10-15-20 years of operational service.
In order to support the development task, ASTi has opted to off-load this functionality to a remote machine, the Studio Development Workstation. This platform in its current form does not support stand-alone development (but more of this later), and must be linked to one or more Target platforms for model development. There are a number of reasons why this configuration is preferred:
- Optimization of the Target runtime framework to support the embedded mode of operation is preferred, versus a hybrid development-runtime platform which introduces overhead and complexities.
- A single development workstation may be employed to service multiple Target platforms in a distributed environment, allowing centralized management of many machines perhaps running cooperatively to support one or more concurrent exercises, or perhaps to support multiple simulators during development.
- A single development workstation may be employed to develop a model that spans multiple Target platforms to form a single tightly-coupled "layout." The development workstation is suited to address the needs of the increasingly common combined-mode, coupled front and back-end training devices (commonly using an OFT or FFS cockpit simulator, and an RCT rear crew trainer, that can be linked to form a single platform), or individual models for each device to support split-mode operation.
- Future development of the Studio is planned to become a piece of application software for installation on a customer provided platform (currently ASTi provides a low-cost platform as part of the purchase).
One of the most important reasons for the existing architecture is to ensure that a model under development will "fit" and run on the intended Target platform. Consider that a stand-alone Studio must somehow "know" what the performance limits of a Target are, otherwise it would be possible to develop a wildly complex model that cannot install or run on any real Target platform. Note that the implementation of the Studio is in ASTi-speak "low profile" - the data exchange between the Target and the Studio is limited to the current area of interest inside the simulation model. So, even though there may be hundreds of signals and data values being computed within the model, only those currently being inspected are passed between the Target and Studio, with the result being that there is virtually no load introduced on the Target when linked to the Studio.
Despite the reasoning presented above, there are situations where it would be desirable to support a stand-alone development mode; perhaps all Target systems are running operationally, or perhaps the Target is deployed to a remote site with limited or zero network access. Although this capability is some way in the future, it is planned that downstream versions of Studio will run without a Target, utilizing virtualization of the Target resources. ASTi will publish further updates on the planned introduction of this capability as we move forward.
More FAQs