Background

A policy is described as an allowed envelop of entities’ actions, in that it defines behavior that is both permitted and required from individual entities in order to be able to operate in a given environment. We consider this definition of a policy throughout our discussion as it embodies core essence of other definitions.

The policy discussed in this study is not merely about granting or denying access to a resource, like conventional definition. It is also different from security policy that maps onto various mechanisms for access control implementation. Conveying conditions on an interaction between two Web Service end-points, like WS policy, is not also the concern of collaboration policy presented in this work. Existing policy definitions consider the owner’s perspective, for example, clients who want to use a resource should respect and fulfill the owner’s requirements. In these three representative cases of the usual use of a policy, resource ownership and access to resources are central points. Collaboration policy is concerned about governing and guiding actions of interacting components towards achieving a common goal. Our policy (i.e., SoS collaboration policy) fulfills this intent by influencing the behavior of interacting components.

Figure: SoS policy and constructing elements

Overall Approach/Method

Our approach to define collaboration policy for system of systems is a hybrid one, in that it combines both top-down and bottom-up approach. First of all, we identified collaboration policy constructing elements. The identification process mainly considers concepts that can be used to capture the required and/or permitted behavior of constituent systems. For this purpose, we analyzed well-recognized characteristics and classification of system of systems. Unlike conventional systems, constituent systems composing SoS are determined to constitute an SoS based on SoS’s desired capabilities. In other words, SoS policy rules need to be derived from SoS’s desired capabilities as it is not possible to assume all specific constituent systems before an environment that exhibit the SoS’s characteristics develops. However, the top-down approach need to be supported by systematic approximation of possible constituent systems capabilities. The bottom-up approach extrapolates constituent systems capabilities based on the SoS’s desired capabilities. To accomplish this, we considered five constructs of collaboration policy that will help to extract capabilities of constituent systems. The constructs includes Environment, Roles, Belongingness, Constraint, and Dedication. This does not imply a need for new capabilities of constituent systems to constitute SoS. It is all about harnessing existing constituent systems’ capabilities for a new environment.

In this paper we discuss how the SoS’s goal can be decomposed into policy rules with minimal assumption of constituent systems’ capabilities. Goals can be decomposed into rules using goal decomposition techniques. Rules can be defined as implementation or action oriented description of a goal. Rules are the least granularity of goal decomposition with regard to policy. Rules show only what the constituent systems should do. We used the concept of a role to represent a set of rules. Roles are a set of rights and duties associated to some specific task. The figure shown below, the top-down view shows the goal decomposition process into action-oriented goals and the extraction of desired capabilities to achieve the SoS level goal. The bottom-up blurred part represents the extrapolation process by analyzing essential characteristics of SoS and approximating the behaviors expected to be exhibited by constituent systems.

Figure: Collaboration policy formulation process

Results

(1) SoS Collaboration Policy Conceptual Model

Figure: SoS collaboration policy conceptual model

(2) SoS Collaboration Policy Constructs

Constructs of a collaboration policy are major components by which collaboration policy can be justified and constructed based on their relationships. We used Maier and Boardman’s SoS characteristics to identify and explain the proposed policy model constructs. It is important to note that some SoS characteristics represent purposes of the collaboration policy, for example, emergent behavior and evolutionary development. These two SoS characteristics cannot be a policy construct since they represent SoS collaboration policy purposes.

• Environment – which is used to represent the nature of SoS under consideration. It is used to show nature of SoS application under consideration in terms of its extent, urgency, size or level with respect to its uniqueness. Our representation using environment as a model construct can give information about how each constituent systems behave in such an environment – indicating the required and permitted behaviors.
• Role – since our modeling approach most dominantly follows the top-down one, which we believe it is preferably applicable in such cases where complete information is not known about constituent systems, we use role to represent tasks that need to be handled in order to fulfill the SoS goal. These tasks are decomposed from the SoS goal. From the roles, it is possible to identify associated actions that can follow or lead the main actions constituent systems used to fulfill the role. The constituent systems’ required or permitted behaviors surfaces the roles constituent systems fulfill with their main actions.
• Constraint– this is another constructing element which we used to represent possible requirements constituent systems may impose to play their roles. The important aspect of the constraint element is not the actual constraints imposed by constituent systems to fulfill the role, rather the possible required or permitted behaviors that can be associated with the constraints of each roles.
• Belongingness – SoS brings together various independent systems to harness a unique feature that none of the constituent systems can provide independently. This implies, it could be strong or weak, but constituent systems make contribution to the fulfillment of SoS goal differently. The collaboration policy should consider this contribution aspect in order to make more effective collaboration. In our collaboration policy model, we represent this idea by belongingness, that determine its value from role and constraints. Belongingness can also give insight about the required and permitted behaviors of constituent systems based on the level of their contribution.
• Dedication – based on the belongingness analysis, it is possible to decide about how important (ranking) each constituent system is to the fulfillment of the SoS goal. However, the ranking obtained from the belongingness need to be supported by the type of commitment (it could be managerial, or operational commitment) constituent systems make available for the collaboration. We represent this concept using dedication, which directly relates to the required and permitted behaviors constituent system can display.

Figure: Collaboration policy construct and corresponding SoS characteristics

Related Publications

• SoSE 2018

Related Tools

• No related tool