Software architecture description languages offer a convenient way of describing the high-level structure of a software system. Such descriptions facilitate rapid prototyping, code generation and automated analysis. One of the big challenges facing the software community is the design of architecture description languages that are general enough to describe a wide-range of systems, yet detailed enough to capture domain-specific properties and provide a high level of tool automation. This paper presents the multi-paradigm challenges we faced and solutions we built when creating a domain-specific modeling language for software architectures of distributed real-time systems.
Software architecture description languages offer a convenient way of describing the high-level structure of a software system. An architecture combines the individual pieces of a system, such as software components and communication networks, into an integrated view. Combining what are normally considered “separate” pieces of the system into such an integrated view allows the relationships between the different elements to be explicitly represented.
Software architecture descriptions serve several purposes. Apart from providing documentation and a high-level view of a software system’s design, they can serve as the basis for automated code generation. Automated tools can generate skeleton code for the software components based on their interfaces and communication links to other components. This ability to translate a high-level description into lower-level implementation artifacts makes architecture description languages ideal for rapidly prototyping applications. Automated analysis can use an architecture description at design-time to answer questions related to security, schedulability and resource utilization.
One of the big challenges facing the software community is the design of an
architecture description language that is both general enough to apply to a wide
range of systems, but at the same time expressive enough to describe problems
specific to individual systems and provide a high amount of automated tool
support. For instance, AUTOSAR [
One alternative to using standardized architecture languages is to create a custom language. This approach can work especially well when implemented with domain-specific modeling languages (DSMLs), which provide an intuitive syntax and ensure that only the relevant architectural concepts are captured. Metamodeling environments also facilitate rapid language development iterations. However, there are several multi-paradigm modeling challenges involved with this approach: architectures contain elements at different levels of abstraction, multiple formalisms and cross-cutting concerns such as security. A viable architecture description language must provide solutions to these challenges.
This paper presents our solutions to a series of multi-paradigm challenges we faced while building a domain-specific language for describing the software architecture of distributed embedded systems. The first challenge is combining multiple formalisms (textual code and block diagrams) to describe component interfaces. The second challenge is to transform high-level scheduling properties of individual elements into a combined temporal schedule. The third challenge is integrating different types of analyses into the modeling language. Even though our approach is tailored to our architecture language, the solutions are applicable across other architecture languages which face similar challenges on a similar level of abstraction, and thus want to provide a similar level of tool automation.
The rest of this paper is organized as follows. Section 2 provides an overview of the modeling language. Section 3 describes how we integrated a textual code formalism with graphical block diagrams. Section 4 describes how we transform high-level scheduling properties of individual elements into a low-level temporal schedule. Section 5 briefly illustrates the opportunities for design-time analysis. Section 6 presents related work, and we conclude in Section 7. 2
DREMS, Distributed Real-time Embedded Managed Systems [
The design-time toolsuite is underpinned by a DSML (an overview is
presented in [
Generated DREMS model Domain-specific model
Input
Compilable code (C++,
IDL) Partition schedules
Build system files Deployment data (XML)
-Schedulability analysis with CPN -Network bandwidth analysis with Network Calculus -MLS security analysis
Deploys on
Networked hardware nodes Comp1
Comp1 Process 1
Comp3 Process 2 MW/Glue code MW/Glue code DREMS OS
The first integration challenge we describe is integrating textual code inside the
graphical modeling language. The use of a textual language was motivated by
the fact that the underlying platform uses a component-based software
engineering (CBSE) methodology [
Thus, inside our DSML, we need abstractions for describing components, which include a suitable representation for IDL. The two main requirements for using IDL inside models were (1) other modeling elements should be able to refer to its properties and attributes, and (2) IDL developed independently from the model should be straightforward to use inside the model. Figure 2 shows the desired workflow.
IDL inside model
IDL generator
IDL
stubs
We had two main choices for how to represent IDL inside our models: a graphical representation or a textual representation. The drawback of using a graphical notation to represent IDL is that it is cumbersome for the user. Essentially, the user builds a graphical representation of the abstract syntax tree (AST) of their IDL. This is especially tedious for designers who already have some familiarity with IDL. The advantage of this approach is that it allows other modeling elements to easily refer to attributes and properties of the IDL.
On the other hand, the advantage of a textual notation is that it is compact, which makes it simple for users to write. It is also easy to import from existing IDL definitions. The drawback of a textual notation is that other elements in the modeling language cannot easily refer to its content. Also, the modeling language itself cannot be used to enforce that syntactically correct IDL is written by the user.
Ultimately, we decided on a combination of a graphical and textual representation. Figure 3 shows the portion of the metamodel (as a UML class diagram) defining the six types of IDL elements represented graphically inside the model; note that they are all subclasses of the abstract class DataType and inherit the Definition attribute. These are the graphical elements that appear in the modeling language.
The integration of the textual IDL language was accomplished by (1)
generating an IDL parser using the ANTLR parser generator [
If the IDL code is syntactically correct, then the integrated parser automatically sets attributes of the corresponding graphical IDL element in the model. The key to the approach is the add-on that is able to (1) parse the textual language, and (2) based on the results of the parser, set multiple attributes on the graphical modeling elements. This is important because it enables attributes defined in the textual language to be integrated into the modeling language. 1. The add-on is invoked from inside the modeling language by clicking the arrow on the lower right-hand side of the element.
IsWellFormed = false Definition = “”
HasKeys = false 4. If the IDL was syntactically incorrect, the IsWellFormed attribute of the element would be automatically set to false.
IDL parser 3. The IDL parser checks the IDL for syntactic correctness. }; 2. User types the IDL code for the element inside the integrated editor.
IsWellFormed = true Definition = “struct Position { …}”
HasKeys = true
5. Because this example’s IDL is syntactically
correct, the following actions automatically
happen:
-The IsWellFormed attribute of the
element is set to true
-The Definition attribute is set to the value
of the IDL.
-The HasKeys attribute is set to true
because the IDL definition specifies a key
using the “//@key” comment.
The next challenge we describe deals with transforming high-level scheduling
properties of individual elements into a combined, low-level schedule for the
target platform. The motivation for this is that the target DREMS platform uses its
own scheduler, namely, a temporal partition scheduler [
In order for the target platform to schedule the temporal partitions at runtime so that the period and duration constraints of each are satisfied, it must be given a valid partition schedule. This partition schedule is a periodically repeating set of time slices called hyperperiods. The partition schedule specifies when to start each partition relative to the start of the hyperperiod. At the end of the hyperperiod, the same schedule is repeated again.
The multi-paradigm challenge with this is how to transform the processpartition assignment graph as well as the high-level scheduling attributes (a period and duration) of individual temporal partitions into a low-level partition schedule that can be used at runtime by the operating system. This schedule should be a part of the architecture description language because users must know at design-time whether a satisfying partition schedule exists and if so, what that schedule is. However, even for seemingly simple combinations of individual partitions, calculating a schedule by hand can be a non-trivial task. Thus the modeling language needs to hold enough information as well as provide a facility to calculate this schedule automatically and present it to users.
Figure 6 shows our solution using a small example. On the left side of Figure 6 are two processes (P1 and P2 ), defined inside the software part of the modeling language. These two processes are assigned to two different partitions (P1 is assigned to T1 and P2 is assigned to T2 ) in the software deployment portion of the language. The schedule calculator is the solution that provides a bridge between the individual temporal partitions and an integrated partition schedule. It is implemented as an add-on to the modeling language using our modeling environment’s extension API and provides a bi-directional interface both to and from the modeling language.
When the schedule calculator is invoked, it queries the model and collects
the individual temporal partitions. Next, it formulates the scheduling problem
as a constraint satisfaction problem [
If a solution to the constraint satisfaction problem is found, then the scheduling calculator must translate this solution into a partition schedule and insert it into the model. Creating the partition schedule from the scheduling calculator is done using the modeling environment’s API which provides programmatic access for setting attributes. 5
This section describes three automated analyses that we built for the modeling language: security of communications, software component schedulability analysis and network quality of service (QoS) analysis. Due to space constraints, we only briefly describe each.
The operating system provides security to applications through spatial isolation (processes run in separate address spaces) and temporal isolation (temporal partitions guarantee that processes get a guaranteed portion of processor time). However, these two mechanisms alone cannot guarantee information flow iso
Duration: 5ms
Duration: 4ms
P1
P2
Process Library (Software Language)
Duration: 5ms
Duration: 4ms
Model translated into constraints
Solution translated into model
lation between applications. This is important because the runtime system is
expected to host both trusted and untrusted (i.e., 3rd party) applications.
Preventing covert channel communication between applications is also important.
Our solution to this problem is a multilevel security (MLS) policy [
DREMS supports systems whose network quality and connectivity may vary
over time. To analyze whether the QoS requirements of processes can be
satisfied with time-varying networks, the modeling language supports QoS profiles
describing the expected network parameters (e.g, bandwidth, latency) over time
and QoS requirements that specify the network requirements of processes. An
automated tool based on the network calculus [
The third analysis relates to the verification of system properties, such as
deadline violations by software components. This approach is based on modeling
the abstract control flow and timing properties for component operations and
then combining them with a formalized model of hierarchical schedulers in the
system (the operating system scheduler and the component operation scheduler)
to generate an integrated Colored Petri Net (CPN) [
Overall, these design time tools provide analyses to both application developers and system integrators to ensure that the system meets the expected requirements and is robust to the runtime constraints imposed by the environment and the infrastructure. 6
There are several architectural description languages and standards that have
similarities to ours, such as AADL [
AUTOSAR [
There exist various approaches for integrating textual artifacts within
graphical modeling languages. XText [
The work in [
Our temporal partition scheduler is based on the temporal partitioning method
described in the ARINC-653 avionics standard [
This paper presented the multi-paradigm challenges we faced when building an architecture description language for distributed, real-time systems. The first challenge was integrating two different formalisms: textual code and graphical block diagrams. The second was computing a low-level runtime schedule from individual, high-level temporal partitions. The third challenge was integrating design-time analysis.
In cases such as ours, where a significant level of tool automation is required, we believe that a custom architecture language tailored to the semantics of the runtime platform provides a big advantage. The alternative, using a standard architecture language, can require adapations to code generators and automated analysis tools to account for semantic differences between the language and the runtime platform, such as scheduling or security.
Acknowledgments: This work was supported by the DARPA System F6 Program under contract NNA11AC08C and USAF/AFRL under Cooperative Agreement FA8750-13-2-0050. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of DARPA or USAF/AFRL.