The development of large, complex, heavy construction equipment can be difficult, time consuming and expensive, even more so if the goal is to design a complete site solution. The example used is taken from an ongoing real project named Electric site. The aim is to electrify a transport stage in a quarry – from excavation to primary crushing and transport to secondary crushing. This will reduce the CO2 95% and the total cost of operation 25%. This paper describes how a standards‐based enterprise architecture model can be used to significantly influence continued system engineering efforts as well as the software architecture for the application development. The enterprise architecture model has been developed specifically to ensure overall management of the site. It is this description, created with an enterprise perspective of the site that is used directly to speed up the development of the systems architecture. The model also details the applications that are required as part of the different systems that will support the overall management of the site.

Architectures, systems, subsystems, and the data that they contain, are valuable assets. Systems engineers and architects must plan for system security from concept inception to retirement to ensure that security is embedded into every part of every process, procedure, system and component as well as in the mindset of the people in the enterprise. While the various DoDAF views contain attributes of security, there are no views for defining system security goals, threats, risks, mitigating elements, etc. and demonstrating how these are integrated and implemented into the operational, system, standards and services views. The Unified Architecture Framework (UAF) has integrated a set of security views that provide engineers a means of defining security goals and requirements and demonstrating how these are implemented throughout the architecture.

Services in the Unified Architecture Framework (UAF) are not just software services. Services can include transport, surveillance, communications, providing healthcare and medical services, etc. The UAF implements DoDAF using the Systems Modeling Language (SysML) as well as the British MODAF and NATO NAF. The DoDAF Service views implement services by duplicating the systems views and labeling the systems elements as services. This causes some confusion with engineers who either implement solution‐based service views or ignore them completely. Even when implemented, they can cause confusion in the model as it becomes difficult to tell if a model element describes a service or a system implementing a service. The UAF implementation of the MODAF services views provides a distinct set of views, concepts and traceability. The Service Oriented Views do not specify how the service is to be implemented, but the requirements for the services. The Resources (Systems) Views implement services in various phases and their deployment will modify the configurations of the system at the very highest level. This paper will show how services views trace from capabilities and how that can be used to define system resource requirements.

The capture of system structure, behavior, configuration, interaction, and compliance is common practice in architectures. These are largely static views showing a specific configuration or behavior. IEEE Std 610.12–1990 defines architecture as “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” (IEEE, 1990) Modeling this evolution or the temporal aspects in architecture frameworks such as the Department of Defense Architecture Framework (DoDAF) was previously problematic. With the release of DoDAF version 2.0, architectures can now take the fourth dimension (Time) into account. The challenge is to identify areas of architecture where time can be modeled and how to take best advantage of it. Also problematic is how to express these concepts without having to expose all the internal ontological relationships upon which DoDAF is built. The Unified Profile for DoDAF and MODAF (UPDM) delivers an implementation of DoDAF 2.0 that provides a clear and concise way of expressing these concepts without requiring the user to become an expert in the DoDAF 2.0 “internal wiring” and detailed ontological concepts. This paper will examine the temporal concepts defined in DoDAF 2.0 and show how time can be effectively integrated into a model to express essential temporal concepts.

Logical or abstract architectures are an essential concept in systems engineering. They are included in the systems engineering handbook, the OOSEM process, the SEBOK, several modeling languages, and the ISO 15288 process definition. A logical architecture is a solution‐independent model of the problem domain used to understand “what” needs to be done, while avoiding defining “how” it will be done. The logical architecture includes all the related logical elements without constraining the architecture to a particular technology or environment. It traces to the physical architecture which defines how to implement the architecture using specific technologies. Logical architectures can be defined using MBSE languages such as the systems modeling language (SysML). They are implicit in the Operational set of views in architecture frameworks such as DoDAF, MODAF, NAF and their implementation in UAF using SysML. NAF has recently changed the title of the Operational views to Logical views to further emphasize the purpose of the views. This paper will define the benefits of using a logical architecture and provide guidance on how it can be implemented.