Each leaf process in a process diagram represents some computation being performed by source code. Process diagrams are often used in conjunction with another notation and style to show the architectures used inside each process, e.g. subprogram call graph, package with/use graph, state machine.
Real-time process diagrams are useful when the timing relationships between various computations and events are important and need to be analyzed and managed. For periodic processing diagrams, there must be some way to specify the periodicity of each leaf process. The temporal properties of things like the start and stop of each periodic execution, data flows, data store accesses, etc. must somehow be either standardized or specifiable in the notation.
Timelines, such as the example shown on the right of the figure above, are often derived from a periodic processing diagram to give insight into the timing relationships between events in a system. Conceptually, processes execute concurrently (as P1 and P2 appear to do sometimes in this example timeline), even though they may or may not be scheduled that way by a particular implementation. The example timeline shows the times at which data flows occur and the times at which access contention for the shared data store might occur. In many actual cases a timeline will show the details of the scheduling implementation chosen (e.g. an off-line schedule, on-line process preemptions and blocking times).
The example in the figure above shows both message passing and access to shared data. Sometimes process diagrams are restricted to use one or the other but not both. Sometimes events are included as a special kind of control flow between processes, and event-driven processes can be introduced. There is often some way to annotate diagrams with information about the type of data flowing between processes or contained in a data store or the type of an event. In a hierarchical diagram, it might be possible for a process to be shared, which is to say that same process may appear in multiple diagrams and have multiple parents. It is also possible to restrict hierarchical diagrams to be strictly tree-like so that each process appears in exactly one diagram and has a single parent.
There are several ways to map a real-time process diagram into an implementation. This generally involves the selection and application of some particular real-time scheduling theory, and a corresponding implementation in some sort of common executive or kernel. Scheduling theories have associated system timing analysis methods that can be applied. The coding guidelines for application modules must specify how processes are initialized, how they interact with the scheduling executive, how data values are sent and received, and how access to shared data is synchronized.
The MetaH architecture specification language supports a real-time process style.
A real-time process style is being used to develop a reusable software architecture for missile guidance and control.