TALENT™ has been designed to be a Open Architecture integration platform for
implementation of automation systems, as opposed
to a custom application. All public interfaces are documented for users to
develop additional components (controllers, Add-ins, etc.).
Some of the important technical features that are visible to the users are:
TALENT™ V4 is designed using the Windows Distributed Component
Object Model (DCOM) architecture. It is designed
according to the n-tier paradigm. The TALENT™ platform is not a single
application, but a number of ActiveX executables and components.
The ActiveX executables can be configured to run in specified computers,
allowing scaleability, and under the specified security only. Some
executables are applications that provide interactive functions, e.g. Operator interface, others
are non-interactive servers that coordinate the run-time environment, e.g. process manager, or act as information
servers, e.g. test information server.
The ActiveX components are shared by run-time applications as well as
preparation-time applications. For example, the same component is used for
creating new tests (preparation time), defining / ordering tests, executing tests
(run-time) and extracting
test properties for test reports (post-run). These ActiveX components can be
directly used by user created applications, e.g. using Excel to extract test
properties through TALENT™ components.
The system is designed with Add-in technology, so that components can be
added to the system to customize a specific facility or subsystem. For
example, new specialized displays and new data system architecture can be added
to the TALENT™ system using Add-ins. The users can develop their own
Add-ins, according to the documented interfaces.
Back to Top
TALENT™ supports automated testing with the Test Automation Language (TAL)
which is an extension of the Microsoft Visual Basic for Applications (VBA). TAL
provides much more flexibility than a "recipe" or a "fill in the blanks test matrix" system.
TAL VBA extensions
are for run-time data access, rule based exception handling classes, timers,
facility control objects, and access to TALENT™ ActiveX components.
The Integrated Design Environment is part of VBA, which shows the user the
expected "arguments" for commands as they are being entered.
Back to Top
The generic data displays in TALENT™ can be copied to Microsoft Word, Wordpad,
Excel, etc., to produce quick ah-hoc reports.
Data I/O configurations can be exported to Excel, sensor calibration
information can be imported from Excel (some customization may be required
dependent on the format).
Back to Top
To provide a scaleable architecture, TALENT™ supports real-time data sharing
among all computers. The data sharing is layered, independent of the physical
connections.
For a slow (10 Hz) system, such as a typical climatic wind tunnel, the data
sharing can be implemented using Ethernet LAN. For a faster system, such as a
Blow Down Wind Tunnel, the data sharing is implemented through networked memory
(e.g. Scramnet). In some implementations, the data sharing mechanisms can be
mixed, e.g. high bandwidth sharing between data acquisition systems and control
systems, low bandwidth to the operator for display only.
Each data acquisition process can determine how to sample its own sourced
data to be shared with other systems. The layered approach allows each data
acquisition process to record timely data from its own source as well as from
other sources if required.
Back to Top
The difference between a test facility and an industrial plant is that a
test facility usually has a static facility configuration and a variable
experiment data configuration; while an industrial plant do not have dynamic
data configurations.
Some users, who have in-house programmers, go as far as writing a new data
acquisition application for each experiment configuration!
TALENT™ differentiates between the facility and the
experiment.
TALENT™ uses the term "facility" to describe those
aspects of the test facility that are relatively permanent and
common to all experiments, or that may pose a safety concern to
either operating personnel or expensive equipment. As a result,
safety and security are primary design
considerations for facility software.
On the other hand, "experiment" activities are
typically more transient, and flexibility is often as important
as security. In some cases, the limit allowed on a test object is much lower
than the capability of the facility, e.g. the maximum load on a test vehicle may
be lower than that of the facility balance. In other cases a test engineer
might wish to push a test object to failure to test its limits, e.g. in a heat
damage test. Decisions made in a test procedure are often depend on data that is
not from the facility equipment, e.g. waiting for stabilization of the test
object temperature. As a result, flexibility and separation from the facility
are primary design considerations for
experiment software.
TALENT™ protects the investment in the fixed facility from accidental damage
that can be caused by the experimenter by differentiating between the users
(e.g. operator vs. test engineers), and between the facility and the experiment
processes. The user / group is identified by the Windows logon identity, the
associated access privilege is administered by the Domain Controller. The
facility manager can decide what should be facility functions that can be
accessed by the operators only. By making
suitable choices, the facility manager can tailor the safety
protection, as well as TALENT™ flexibility, to the precise needs
of the research team. Conversely, the test engineer can also decide what should
be the test condition limit in a test, separate from the facility equipment
limit.
| 
