Application creation and management

Is there a limit to the number of function boxes?

There is no limit imposed by Gedae on the size of the graph or the number of function boxes contained in them. The memory on the development system, and ultimately on the target hardware, will limit the size of the application.

In a heirarchical graph, can I look at the tables for just one hierarchical box?

The abilities that are available enable you to hide, rearrange, collapse, and expand various table entries. For your convenience, you may save and restore the formatting of many of the tables.

Can GUIs be used with Gedae applications/launch packages?

Yes, as long as the host supports the X/Motif graphical interfaces. The following are the three ways to add a GUI:

1. Using Gedae's Primitive Library (as described above)
2. Using a 3rd party GUI builder
3. Creating the dialogs using X/Motif commands directly in C-code

Discussion

Gedae now includes a GUI Primitive Library, which supports the building of application GUIs. Two new primitive types, Eval and Trigger primitives, have been defined and implemented, significantly increasing the overall Gedae capability. Both of these primitive types process parameters rather than data streams. The purpose of an Eval box is to drive the values of its output parameters from the values of its input parameters. Trigger boxes differ from Eval boxes because they fire only when an input trigger has been received. Any of the input parameters to Trigger primitives can be defined as a trigger. The introduction of Trigger and Eval primitives has made GUI building a straightforward development. The GUI Primitive Library is included with Gedae Version 3.0.

Future

Three application notes will be written to show how to build a GUI using each of the three methods described above.

Can a Gedae application be fault tolerant?

One requirement for many embedded systems is to carry out Built In Test of the underlying hardware resources and, when a hardware fault is identified, to remap the application while on line to exclude the faulty hardware.

In a final stand-alone Gedae application would these issues need to be addressed by other appropriate control software, produced outside the Gedae environment and operating 'above' the Gedae command program interface, or is it possible to address both of these issues through appropriate flow graph design? That is:

1. Is it possible to perform Built In Test using portions of a flow-graph to manipulate status data, derived from the underlying operating system or hardware?
2. Is it possible to enable reconfigurability using appropriately designed flow-graphs, with redundant processing threads which can be switched in/out using valves?

Discussion

Gedae supports implementing fault tolerance and isolation using either command programs or Gedae flow graphs. The solution that we will use in both cases has a health check task running on each processor and that information is being reported to a central processor that is controlling the application. The application decides after some period of not hearing from an embedded processor that it is dead and reassigns its duties to a spare processor. The solutions described are the two extremes. The first does everything in a command program. The second does everything on the embedded system. Of course there are intermediate solutions which are a mix of the two solutions presented.

Using the Gedae Command Program Interface

Figure 1 is an illustration of a system that uses a command program and multiple launch packages and health check tasks that were developed outside of Gedae . The command program is monitoring the health of each embedded processor by querying a health check task that is running on the processor. Alternatively, the health check task could report back on a periodic basis and the command program could monitor those reports. Since the health check and Gedae launch package tasks are separate tasks, it is necessary to have a multitasking OS running on the embedded processor. When the command program determines that a processor has failed then it disconnects that processor, starts a launch package on a spare processor, and reconnects the source to the new launch package. The sequence of operations is:

1. Recognize that an embedded processor (Processor 2 in Figure 2) is not replying.
2. Disconnect the command program from the health check process.
3. Disconnect the data source from the Gedae launch package running on the nonresponsive processor.
4. Load launch package 2 on the spare processor.
5. Connect the data source to the new launch package.
6. Start the new launch package.

The result is illustrated in Figure 2.

Using a Gedae Graph

Figure 3 is a flow graph that shows how one might implement fault detection and isolation within a Gedae flow graph. The same graph is annotated in Figure 4 to show how the graph would be mapped to processors. The function box Sink has logic in it that feeds back information to the controller indicating that a data set has been successfully processed. The function box Control monitors the health check inputs to determine if any processors are not responding. Of course there is the double check to see if the Sink box has reported success. The Control box will hold the data set on the input until the Sink box has reported the completion of processing. It will then discard that data set. If the Control box determines that a processor is not responding then it will reassign any data sets that were assigned to that processor to another processor. Notice that in this scheme all the mode processors are really on equal status. There are simply enough of them to make sure that even with the loss of 1 or 2 or N of them there is still sufficient processing power to maintain the required throughput. This scheme is dependent on the source and sink processors not failing. Other schemes can be developed that provide redundant source and sink processors, and improved fault tolerance.

Currently the valves/merge combinations cannot be distributed so they would be replaced with nondeterministic boxes that are available in the core Gedae library.

Using a Gedae Graph

Generally using a command program will be more cumbersome and slower but will use less program memory. Generally using a Gedae graph will provide for quicker isolation but will use additional memory. The biggest difference in the implementations is that the command program will load and unload smaller launch packages whereas the Gedae graph will contain all the necessary code. Of course, loading and unloading launch packages and making and breaking connections is more time consuming than switching between code that is resident in memory.

Figure 3

Figure 4

How can we archive all information for a flow graph - graphs, primitives, parameter settings, group settings, etc.?

The archiving portion of the FGU has been implemented and will be included with Gedae 3.1. Using the utility, a graph and all its associated files can be archived by simply selecting the graph and clicking on "Archive Graph." An archive browser has been developed to manage existing archives, allowing the user to add files to the archive, remove files, and restore portions (from a single file to the entire set) of an archive.

Discussion

While developing a project, Gedae creates many files for the user. Each graph and subgraph is saved as a separate file, each primitive is a separate file, each group or parameter setting is a separate file, etc. Keeping track of all these files can be tedious. A utility is needed to do the standard file and directory management routines, such as copy, delete, move, and archive, for Gedae graphs.

The Flow Graph Utility (FGU) is being developed as a stand-alone utility to manage the files created by Gedae. The entire set of files that describe a graph will be treated as one entity by the FGU. The utility will be able to copy, move, and delete graphs, copy and move a directory full of graphs, archive a graph and restore the archive, and delete all backup files from the directory structure.

Future

The rest of the FGU will be developed for future releases.

Does Gedae support automated requirements traceability?

No, Gedae does not provide automated requirements traceability.

How can one get a figure for the number of C sources instructions generated by Gedae for an embedded application?

There are two libraries supplied by the Gedae installation that are used by the embedded executable.

1. $Gedae/<host>/<emb>/lib/libembedded.<archive_suffix>
2. $Gedae/<host>/<emb>/lib/libemb_fncs.<archive_suffix>

1. Dynamic and static schedule execution engine. (schedules when to reset and run the Gedae primitives)

   5500 Lines of code.

2. Communication protocol layer. (host-to-emb communication and emb-to-emb communication)

   Typically about 1000 Lines of code (depends on each embedded system)

3. Utility functions. (add, mult, fft, etc.)

   About 4000 Lines of code (depends on the embedded system), about 220 Utility functions files.

1. Generally only the functions used are linked in. For example, typically only a small number of the 220 utility functions are included in the executable, and if the dynamic Gedae runtime kernel is not needed, it is not included.
2. Most of the functionality has been optimized to reduce duplicate code or unused code. This is to keep embedded executable size as small as possible.
3. When comparing these numbers with the lines of code produced by hand coding keep in mind that for small problems (probably not realistic problems), the very general capability of Gedae makes the Gedae line count larger than the hand coded line count. On the other hand, for larger problems the line count will be much larger for hand coded than the Gedae line count. This is the result of the high level of abstraction used by Gedae. Typically only the number of lines associated with the primitives (see below) will change.

1. run an embedded graph
2. cd embedded/<graph_name>
3. load exec-.c into an text editor
4. The list of generated C files is represented by the functions beginning with a serial number (Ixxxx_<function_name>). For example, this comes from the demo/bench1bench1 graph:
   • void I0008_mx_adjoin(void);
   • void I0008_mx_trans(void);
   • void I0006_vx_cut(void);
   • void I0006_vx_fft(void);
   • void I0006_vx_ifft(void);
   • void I0006_vx_multV(void);
   • void I0006_vx_multVX(void);
   • void I0006_vx_mux(void);
   • void I0006_vx_subvec(void);
   • void I0006_vx_zfill(void);
   • void I0005_copy(void);
   • void I0005_dequeue(void);
   • void I0005_enqueue(void);
   • void I0005_recv(void);
   • void I0005_send(void);
   The source file you would look at are:
   • mx_adjoin.c
   • mx_trans.c
   • vx_cut.c
   • vx_fft.c
   • vx_ifft.c
   • vx_multV.c
   • vx_multVX.c
   • vx_mux.c
   • vx_subvec.c
   • vx_zfill.c
   • copy.c
   • dequeue.c
   • enqueue.c
   • recv.c
   • send.c

• /home/jdoe/gedae/solaris/object/embeddable/verctor/complex/vx_cut.c
• /home/jdoe/gedae/solaris/object/internal/send.c