A.ICS has ~40 employees
and is in the process of hiring additional engineers.
2. Product
Q.How long has your product
been available?
A.ICS's core product,
SCL,
has been marketed since 1998
Q.How can we evaluate
the SCL system before purchase?
A.Evaluation copies of
SCL are available contact ICS for availability.
Q.Describe at a high
level some typical architectures for installed systems using your product.
Summarize the data rates of these architectures. Summarize what is required
to incorporate your product within a user's system.
A.Typical SCL
Monitor and Control Architectures are UNIX workstation class computers
using an Ethernet backbone for connectivity. The core element of SCL has
a unique feature in that it can be used in embedded applications and can
even be ROM'd. Possible SCL monitor and control applications
encompass the following areas: simulations, spacecraft monitor and control
workstations, remote tracking stations, telemetry advisory systems, test
equipment controls, embedded controllers for satellites, embedded controllers
for communications equipment. All applications of the SCL system are real-time
monitor and control tasks. SCL is normally the core product in a control
system. The SCL system allows the user to add keywords as required to control
other software tasks or functions linked into the core SCL system. Communication
between elements of the system are normally accomplished via our software
bus (Documented as the SCL Message Broker). The core control system is
isolated from the graphics front end by a data server. The data server
is middleware which translates from SCL's Application Programmer's Interface
(API) to the graphics product's API. Other 3rd party products or custom
code are integrated into the system by registering to consume or produce
packets on the software bus.
Q.What is the size of
the largest application built using this product? How many telemetry parameters?
How many block diagrams? How many spacecraft and ground hardware commands?
A.The largest application
of SCL in terms of sheer data points would be the Kennedy Space Center
(KSC) Remote Monitor and Alarm System (RMAS). More than 80 copies of the
SCL real time engine are embedded on single board computers (SBCs) throughout
the KSC campus. The SBCs monitor a local rack of fiber optic communications
equipment. All remote computers report to a single SPARCstation running
SCL and displaying graphical alarms when a piece of equipment fails. More
than 64,000 data points are monitored with this system. Hundreds of screens
with 10-50 objects per screen are monitored as part of the RMAS system.
Another SCL application, the FLEETSATCOM simulation delivered to the EOCT
contains more than 3,300 commands which are monitored and appropriate telemetry
points simulated. See our Products
Hub for more specific implementation information.
Q.Has the product ever
been incorporated in an Object Oriented environment? How many objects were
there?
A.ICS does not have a
count of the number of C++ classes defined for SCL.
A.Yes, successful applications
have been built using selected portions of the SCL system. SCL is modular
in nature and is distributed with an API. Portions of the system can be
omitted and user-supplied processes can replace the functionality of portions
of our system. SCL is shipped with or without a graphics product. The user
can develop a custom graphics front end and interface to SCL using our
API. SCL has been used as a core control system as
well as a value-added to an existing system. The system is very flexible.
Q.How long does it take
to initialize your system?
A.Assuming a SPARCstation
10 as a baseline, loading the shared memory database for 2,000 data points
takes less than 5 seconds; this only needs to be done after reboot, or
when the database source has changed. Bringing up SCL processes takes less
than 10 seconds. Most of that time would be consumed with loading a nominal
sized knowledge base for the Expert System. Bringing up the Sammi
graphics engine task less than 20 seconds before a login dialog box
appears. The SCL and Sammi systems
can be shut down in less than 5 seconds.
Q.Does your product provide
a checkpoint capability? How long does it take to restart the system from
a checkpointed state?
A.No checkpoint capability
is provided by SCL at this time.
Q.How frequently is the
product updated to incorporate new features and fix bugs? Is the list of
known bugs made available to users?
A. SCL is released based
on the needs of new features by our customer base.
Generally, we have a new release come out quarterly.
The list of known bugs is shipped with each
release..
Q.Are new releases upward
compatible?
A.With the exception
of major releases such as the Version 2.0 database
manager re-write, databases are upwardly compatible. Scripts and Rules
written using SCL are almost always upwardly compatible. We normally add
keywords rather than remove them.
Q.What type of configuration
management procedures are used for your product? Are these CM procedures
documented? May we review them?
A.SCL is managed internally
by ICS. We use a Revision Control System (RCS) to track changes to the
software source code. We use Purify to
check code for memory leaks, and other tools to profile the code performance.
We have a suite of scripts and rules which comprise our regression test
suite. The regression test suite is used to verify the SCL system prior
to each release. We manage all releases from a single site, and have a
database with contact and configuration information for each site which
receives SCL. We track bug reports through our Software
Problem Report (SPR) database. We track enhancements through our System
Enhancement Report (SER) database. We documented our CM procedures
more than a year ago and we are currently revising then to reflect our
experience with the procedures. We have begun an effort to move towards
ISO-9001 for Quality management and are documenting our procedures using
Quality Process Language (QPL) nomenclature. Our procedures are available
for review.
Q.Are you willing to
put the product including the source code in escrow?
A.ICS is willing to place a
specific version of the source code in escrow at customer expense. ICS does
offer the SCL system as Source Alliance and can be escrowed at any time.
.
Q.Has your product been
successfully used on a DEC Alpha, a SUN SparcStation, or an HP 9000 workstation?
Do you have these platforms in house and are they available for resolving
problems?
A.SCL has been ported
and operated on both the DEC Alpha and the SUN SPARCstation. Sun SPARCstations
are our main development platforms. ICS is a member of the Sun and HP developer's
programs. We recently have ported SCL to the HP workstation and delivered
to Goddard Space Flight Center. We HAVE ported SCL to the Alpha platform,
but the Alpha version of SCL is not actively maintained at this time, due
to lack of interest in the product from our customer base. We no longer
have an Alpha computer available and because our customer base has not
yet embraced this platform we do not have any current plans to purchase
an Alpha. If a customer requires an Alpha version of SCL, ICS can rehost
the current version of SCL on the Alpha in approximately 3 weeks.
Q.Has your product been
successfully used with DEC UNIX, SUN Solaris or HP-UX? Do you have these
operating systems in house and are they available for resolving problems?
A.SCL has been successfully
operated on the SUN Solaris and DEC UNIX (ULTRIX). ICS has ported SCL to
the HP-UX and delivered to Goddard Space Flight Center. We have HP's and
DECstations at both of our locations.(VAXstations also)
Q.How do you view the
product? Is it a turn-key system or does it require your support to use
it properly?
A.Our system does not
require active support from ICS for it to be integrated into a customer's
system. We have customers that merely take delivery of SCL distribution
tapes and rely only on telephone support from ICS. Loral Federal Systems
is an example of a customer who has built a product around SCL. However,
it should be noted that SCL is not a turn-key satellite
ground control center. SCL serves as the core software element of a
satellite ground control center. SCL facilitates the integration of other
COTS products to assemble a ground control center that complies with customer
requirements more closely than a turn-key system is able and, often, at
a lower cost. SCL has a documented API which can be used by the customer
to develop a larger system around SCL. ICS is available on a contract basis
for training, consulting, and Systems Engineering Support as required.
Q.What type of support
contracts are available? How long do you continue to support a product
after a newer version is released? Are training courses available?
A.The system is sold
with one year of technical support mandatory. This includes phone support,
software and documentation upgrades, and Internet support (e-mail and World-Wide-Web).
Support contracts are paid for on a yearly basis. ICS maintains both the
current and previous versions of SCL. ICS has arranged for long term maintenance
of specific versions of SCL at the request of the customer. Training
courses are available at a customer's site.
Q.Which COTS products
has this been successfully integrated with? (C & C, C & T Processors,
HCIs, Expert Systems, DBMS, Xshell, HCI test tools such as XRunner, etc.)
Provide a high level architecture and characterize the level of difficulty
of each.
A.Talarian, TCL/TK, COMET,
LabViews, CLMS Message Broker, ToolTalk, STK, Sammi, DataViews using
rtServer, SL-GMS (not current), Motif, OpenLook,
FLEXLM License Manager. SCL uses a set of C++ class libraries to abstract
the external interfaces (physical and virtual). These class libraries can
be extended or overloaded depending on the environment. If we do not currently
support the interface, a new class can be written which calls the 3rd party
product's API. Since most commercial products contain a high-level API,
interfaces to them is normally not a difficult task once the product is
understood.
Q.Is your product dependent
on any third party vendors?
A.All 3rd party products
can be removed from the SCL system if necessary. We are moving closer to
not having any 3rd party product required for the SCL system. We use
DCE, CLMS or ToolTalk as Message Brokers, and
Sammi or LabViews as graphical Front Ends. Each of these products are
abstracted from the core system using
a C++ class library. A client-server model has been used so that servers
for 3rd party products can be substituted as needed. These servers are
nothing more than middleware which calls each product's API. These can
be swapped out as needed.
Q.Is the product CORBA
compliant? If no, how difficult would it be to make it CORBA compliant?
A. The FUSE Satellite Control
Center has implemented the IONA CORBA product on the SPARC platforms. ICS
has been working to abstract the message broker for all tools in the SCL system,
so that we can change the underlying message broker technology with little or no
effect on the system. Currently, the customer base is not excited about
spending $10K-30K on software liceneses for something they really don't
see.
Q.How many users can
operate this product on a network at one time? What is the maximum number?
A.No user limit.
Q.Are there any restrictions
on exporting the products overseas? What were the problems, if any?
A.ICS was granted a Dual-Use
status for the SCL product. In the wake of the September 11th, 2001
bombings, we are reviewing all exports on a case-by-case bases to see if ITAR
restrictions apply in the release of our software.
Q.Are there any critical
functions missing from the current product but scheduled for release in
the future?
A.No.
3. Interfaces
Q.What network interfaces
are supported (Ethernet, FDDI, ATM)?
A.Since SCL is purely
a software product, the physical and transport layers of a network are
largely hidden from the SCL software by the specific network protocol that
is being employed. SCL systems have been deployed on a variety of Ethernet
networks using TCP/IP protocol stacks. Please call for specific questions.
Q.What external communication
protocols are supported?
A.SCL supports TCP/IP,
ToolTalk, DCE, and some Custom Serial.
Q.Are UNIX sockets supported?
A.SCL supports UNIX sockets
as a default.
Q.Are Remote Procedure
Calls (RPCs) supported?
A.SCL supports ONC/RPC
and DCE/RPC.
Q.Can custom software
be integrated into the system? At what points can this be done? (callbacks,
forks based on a rule firing, etc.)
A.SCL supports the integration
of custom software and COTS software modules. These modules can be integrated
into the system via: a software bus, RPC's, BSD sockets, or linked directly
with the SCL Real-Time Engine.
Q.Does the product support
event handlers?
A.SCL supports event
driven scenarios with Rules.
4. Telemetry Parameters
Q.What types of Engineering
Unit(EU) conversion are available? (discrete states, piecewise linear interpolation,
polynomials, etc.)
A.SCL supports discrete
state conversion and polynomial conversion as intrinsics. Additional conversion
functions can be added to the SCL Data I/O software as callable functions.
Q.Can the EU conversion
be modified by the operator in real-time?
A.SCL database parameters
can be modified in real-time.
Q.Can different operators
have different EU conversions for the same system telemetry items?
A.Yes, multiple databases
can be loaded into SCL's shared memory. Operators requiring different EU
conversion may then attach the SCL system to a database with the different
EU conversion parameters.
Q.What capabilities are
provided for handling telemetry values once they are in the product? (Automatic
limit checking, alarm notification...)
A.The SCL Data I/O and
Real Time Engine software support: change detection with aperture, limit
checking, alarm level checking, smoothing, rule evaluation and execution,
logging and user-defined functions.
Q.Are telemetry limits
adjustable by the operator in real-time?
A.Yes, SCL database parameters
can be modified in real-time.
Q.Can different operators
have different alarm limits for the same system telemetry items?
A.Yes, multiple databases
can be loaded into SCL's shared memory. Operators requiring different EU
conversion may then attach the SCL system to a database with the different
EU conversion parameters.
Q.Can an alarm notification
inhibit flag be included into the database? When inhibited, can alarm notification
be shut off? How would this be done?
A.SCL database records
can be tailored to meet a system's requirements. An alarm notification
inhibit flag can be added to specific database record types or all database
record types. Such a flag could be modified to the inhibited or released
state at anytime by the operator, an SCL script or an SCL rule. The Sammi
graphics product (as well as other products)
have strong alarm capabilities that can be exploited.
Q.Can additional telemetry
item attributes be incorporated into the database? (For instance, an "in
telemetry format"/"not in telemetry format" flag.)
A.Yes, see above.
Q.At what points in telemetry
processing can C++ code be incorporated? (Get/set functions, alarm callbacks,
etc.)
A.As implemented in several
SCL-based systems, when a telemetry item is processed, the Data I/O software
accesses a table of functions that are to be applied to specific telemetry
types. The table contains the SCL intrinsic functions such as change detection
and polynomial EU conversions. Also in the table would be any system specific
processing function that has been implemented.
Q.Are there any limitations
on the size and frequency of telemetry data imported into the system?
A.Loaded question! Limitations
are based on the complexity of the decommutation, processor bandwidth and
loading of the system. Due to SCL's modularity, processes can be moved
to other processors as necessary to distribute the load. Also commercial
front-end decom systems (Loral 550, Quad 5, etc) can be used to decom and
filter high-bandwidth data. ICS has performance benchmarks which we can
supply.
Q.How extensive is the
decommutation capability?
A.Currently, packetized
data and sub-commutated data can be supported. Additional capabilities
are easily added by ICS or the customer.
Q.Is there any limit
on the number of telemetry values that can be handled?
A.An individual SCL database
is limited to 65535 entries.
5. Inference Engine
Q.What triggers the evaluation
of an inference engine rule?
A.A rule is evaluated
when a database mnemonic that is referenced in the rule's premise changes.
In the case of an analog or real data type, the magnitude of the change
may be specified. The rule is fired if the rule's premise evaluates to
TRUE.
Q.If rules are normally
evaluated based on one variable changing value, as opposed to upon receipt
of a complete frame of data, how would one control the evaluation of rules
to only process a frame of data?
A.The SCL RTE evaluates
a rule or rules when it receives a change notice. The SCL system gives
the user the option of sending a change notice whenever an individual item
changes. Alternatively, the user may setup the system so that an entire
frame of data is entered into the SCL database before change notices are
sent to the RTE for the items in the frame that have changed.
Q.Can rules be modified
in real-time? How is this done?
A.Individual SCL rules
can be modified in real time by loading a new version of a specific rule.
The new rule will replace the existing rule in the run time system. Rules
(and scripts) are loaded by issuing the Load directive.
Q.Can symptoms and fault
classes be organized in the engine?
A.General classes of
rules can be grouped by their category or subsystem fields
as defined in the Rule header. Rules may be activated or deactivated based
on their category or subsystem.
6. State Recognition Engine/Summary
Status Generator
Q.What can be done using
the SRE?
A.The SCL RTE allows
a wide variety of states to be defined for a discrete item. Rules can reference
one or many of these states. SCL Derived Items can be used to indicate
status conditions (satellite_ok, etc). Derived Items are normally calculated
by Rules.
Q.Does the SRE support
more than just good/bad states (for example:trickle_charge1, trickle_charge2,
full_charge)?
A.See above.
Q.Can states be modified
in real-time? How is this done?
A.State values are contained
in the SCL Database and can be modified in real-time. Rules which monitor
state changes must be re-compiled and reloaded. This can be accomplished
by pausing the Real-Time Engine, loading the new rules and restarting the
RTE. The process does NOT need to be brought down and then back up.
7. Commanding
Q.What capabilities are
provided for commanding ground hardware? Briefly, how would a user set
up a hardware interface?
A.Hardware access is
accomplished via the use of I/O Definition Procedures (documented as IODefProcs)
or via customization of the SCL DB Manager. The SCL DB manager is designed
to support such customizations.
Q.Are there any constraints?
What is the highest rate of commanding that has been achieved with this
product? xx commands per second?
A.Generally, the uplink
interface is the bottleneck in commanding a spacecraft. We have not seen
any specifications for an uplink we can't keep up with. Commanding devices
can be accomplished at roughly the speeds of rules firing. We measured
2,800 rules per second firing on a SPARCstation 10 loaded with just SCL.
Q.Can the product accept
sets of commands generated from other s/w as opposed to an operator?
A.The SCL software has
an interface to accept command sets generated from other processes.
Q.What facilities are
provided for adding a custom interface? Is it possible to interface with
C++?
A.There are several points
in the SCL system where custom command interfaces can be added. Most of
SCL is written in C++. Functions written in either C++ or C are easily
interfaced with the SCL software.
Q.Within the commanding
process, where can custom code be incorporated?
A.Custom code can be
added at several points in the SCL system. Custom code can be added as
an external function (XFCN) which allows the creation of a new compiler
keyword to match the custom code. Or custom code can be added as an I/O
Definition Procedure (IODefProc) where the custom code is associated with
one or more command database items.
Q.Does this product output
single commands or can the product output command procedures?
A.If the "command procedures"
referred to by the question are Stored Command Blocks for a spacecraft,
SCL can load blocks of memory to the uplink with the load directive.
command
procedures are ground system command blocks, SCL Scripts would be the
functionality used for this case.
Q.What is the time-tagged
resolution for sending commands? For logging them?
A.The SCL system does
not maintain time. Time must be provided to the SCL system. SCL does not
place any restrictions on the time resolution.
8. Database
Q.Briefly describe the
design of the database?
A.The SCL real-time database
is a shared memory section. The database is designed for high-speed real-time
access from multiple processes. The database records are indexed from a
master lookup table by the record ID. The data structure pointed to by
the lookup table can be a variable length record. Off-line tools are used
to define the database records. Database records are defined using a "template".
A template is equivalent to a schema in RDBMS terms. The SCL database is
designed with an OO perspective. Records can inherit attributes from other
records, and a new schema can be defined for each customer. The corresponding
"access functions" are added to the SCL RTE to allow access to elements
of a record from the SCL scripting language. The keywords for the elements
are also added to the SCL Compiler.
Q.Are facilities provided
for interfacing with an external database?
A.Currently the SCL database
tools accept and ASCII records in our template definition language as well
as a tab-delimited format (common export format from DBMS products).
Q.Can SQL or other database
command languages be used to interface with with the internal database?
Can data be imported to and exported from the internal database?
A.Currently we do not
have a SQL interface to our database. We can export our database to our
template definition language as well as a tab-delimited format (common
import format from DBMS products).
Q.How is the archived
data stored? How much telemetry and commanding data can be stored in the
internal database? What is the time-tagged resolution for this data in
the database?
A.SCL allows the user
to "listen" on the software bus. The user can then archive the data in
whatever format they wish. SCL does not force the user to purchase a DBMS
product. The internal database contains 1 copy of each command and telemetry
object. An individual SCL database is limited to 65535 entries. Time tag
resolution is user defined.
Q.Has the product's archived
data been integrated with any other post-analysis COTS products?
A.We have not addressed
that as part of our core product. We allow the user to choose the RDBMS
or OODBMS they wish and integrate the Archiver with other 3rd party
product for data analysis.
9. Scripts
Q.Can new operator requests
or verbs be added to the operator input language? Can existing ones be
modified? Briefly describe how.
A.New SCL statements
are normally added by using the External Commands (XCMDs) or External Functions
(XFCNs) capabilities. The keywords are added to the SCL Compiler's configuration
file (a data file, not code) to allow the compiler to recognize the new
keyword. Code for execution of the XCMD or XFCN is added to the application-specific
code in the SCL RTE. The user links that code with the RTE for execution
of the function. Another method available is to have the SCL RTE send a
packet on the data bus (or TCP/IP sockets) for any key word it doesn't
recognize. An application process can register to consume that packet and
will be responsible for parsing and execution of the statement. XCMDs and
XFCNs can be written in C or C++.
Q.Can these verbs be
used to invoke C++ routines?
A.SCL verbs can be used
to invoke C++ routines. See above.
Q.What is the processing
rate for script statements?
A.Benchmarks for Rule
execution on a lightly loaded SPARCstation 10 was 2,800 rules per second.
Each rules was comprised of ~10 SCL source statements.
10. Mission Support
Q.Does your product support
configurations of multiple satellites and off-line users? Describe briefly
how this would be done?
A.Yes, by loading multiple
databases in SCL's shared memory. Currently limited to 6 simultaneous satellite
passes.
Q.For different users
(operations, training, post-analysis, etc.) how does the startup of the
system vary? Can different startups be automated?
A.SCL has, as a system
intrinsic, a login capability that has not yet been used in an operational
environment. Sammi
contains login capabilities which determine access levels as login time.
The SCL Data Server used as a bridge between SCL and Sammi has access to
this information. The SCL system does support automated startups.
Q.Does your product support
the concept of authorizations? (For displays, commands, acces to equipment,
etc.)
A.SCL Constraints can
be used to have multi-step authorizations for commands. This can also be
customized as part of the SCL system. The login access level or fields
in database items can also be used to control access information. ICS is
investigating using DCE Access Control Lists (ACL) for DCE based systems.
11. HCI
Q.Is an internal HCI
provided?
A. Sammi or other competitors) can be used as the graphics engine for real-time display. SCL is not locked into this product. The interfaces are abstracted to allow us to integrate with other 3rd party products.
Q.Is the product compliant with MOTIF/XWindows?
A.Yes.
Q.What layers are provided by the internal HCI?
A.N/A
Q.Was a GUI builder used to create your displays? Which one?
Q.Can custom displays
be created and used with the product? Briefly describe how this would be
done?
A.Yes. 3rd party products
such as Sammi contain
a graphics editor to allow the screens to be defined. The graphics engine
manages these screens in real-time. See the Sammi Format Editor documentation
for more details.
Q.Would substituting
a different HCI layer cause breakage?
A.All interfaces to an
HCI are handled by the SCL Data Server. An interface to another tool is
isolated to this process and is not a significant amount of code to re-write.
This middleware bridges between SCL's API and the Graphics Product's API.
Q.Can the product interface
with displays created by a GUI builder such as BX/LOOX? How can this be
done?
A.The architecture would
need to encapsulate the information about the graphics object such as shape,
scale, etc. SCL sends and receives data to "graphics objects". SCL does
not know if it is a strip chart, thermometer, etc. This is externalized
from SCL. See above.
Q.Is a context-sensitive
Hypertext access capability/widget provided?
A.As part of the Graphics
product, not as part of SCL. We have our documentation in the form of UNIX
man
pages, and World-Wide-Web pages.
Q.How often can telemetry
values be updated on a display?
A.This is a function
of the graphics engine. The user normally sets the object up to be polling
or data driven. The polling rate is variable.
Q.Does your product support
function keys?
A.SCL does not exploit
the function keys due to the need for portability across platforms.
