Methodologies and Handling Techniques of Large-Scale Information in Decision Support Systems for Complex Missions
Abstract
:1. Introduction
- Decision Support System (DSS): This system plays a pivotal role in the design, monitoring, and real-time execution of missions. It includes a range of functionalities such as (a) designing the mission’s blueprint, outlining objectives, strategies, and resources, (b) monitoring the mission’s progress, ensuring adherence to the predefined plan, and (c) facilitating real-time adjustments and decision making during mission execution to respond to operational conditions of a dynamic nature.
- Information System (IS): This system is integral to data/information management, with functionalities including (a) managing input and output data/information, ensuring the accuracy and relevance of data used in decision-making processes, (b) handling data/information, encompassing storage, retrieval, and processing operations, (c) responding to Requests for Information (RFIs), ensuring timely and accurate dissemination of information, (d) implementing a computationally efficient classification of data/information to enable efficient categorization and retrieval, and (e) categorizing data/information thematically, which facilitates easier access and analysis for specific mission aspects.
- Complex Mission Support System (CMSS): This kind of system is designed for executing intricate missions, with features such as (a) producing detailed records of actions taken (log files), providing a comprehensive procedure footprint for efficient analysis, (b) predicting new intermediate (crucial for the mission) actions’ nodes, facilitating proactive planning and resource allocation, and (c) executing operational procedures efficiently, ensuring the seamless implementation of mission-critical tasks.
- 1st Methodology: Use of information organization of the incoming data in the CMS system, based on purpose. This methodology emphasizes purpose-driven information organization. Aligning operational procedures with specific purposes aids efficient information organization correlating each action with the data required for mission support [24].
- 2nd Methodology: Use of thematic decomposition of complex operational procedures based on their thematic content, as well as the geographical area where they take place [25].
- 3rd Methodology: Use of a novel mission design algorithm for identifying key intermediate objectives, enabling the CMSS to easily and flexibly handle any kind of complex operational procedure, following crucial intermediate steps in order to accomplish a mission successfully.
- 4th Methodology: Use of a novel system architecture called a “teleological structure” or “thematic content map”. The aforementioned architecture ensures the sustainability of a complex system because it resembles the way in which the human mind works, correlating each subject or issue that it is called upon to address with the corresponding sub-sets of data and computational methods required to solve a particular problem or issue. Components of the teleological methodology are used in the three aforementioned methodologies by appropriate adaptation to CMSSs. So, a CMSS that implements the teleology method gains flexibility and functionality by simplifying the operational procedures/processes without negatively influencing the successful completion of a mission [26].
- 5th Methodology: Use of an organization of geodata called “themes over maps”, that optimally fits the aforementioned teleological structure. The themes over maps approach is more suitable for complex missions than the frequently applied architecture called “maps over themes” because it is totally aligned to the way in which the human mind works, correlating each subject or issue with the problem that it is called to solve [27,28]. Components of this structure are used in the entire system by suitable adaptation to the IS, which is interconnected with the CMSS. So, the integrated system that implements the themes over maps structure can provide to any of its components the actionable information required for the successful completion of a mission.
1.1. Related Works/Existing DS System Methodologies
1.2. The Structure of the Present Study
- In Section 1, an introduction is provided, along with a proposal for a novel system structure and methodologies that merge a CMSS with an IS, forming an integrated DSS.
- In Section 2, the focus is on the critical challenges and methodologies involved in managing data and improving the decision-making process in complex mission scenarios, elaborating on the development and organization of CMSSs and ISs. This section is organized into several sub-sections:
- Section 2.1 discusses the data requirements and structural design necessary for creating CMSSs.
- Section 2.2 outlines the specific data needs of operational specialists for successfully executing complex missions using CMSSs.
- Section 2.3 focuses on addressing the challenges associated with managing extensive datasets in ISs.
- Section 2.4 explores the unique aspects and design challenges of SSs.
- Section 2.5 covers the structured development of data cores for efficient information by describing five methodologies for organizing data and complex operational processes in DSSs.
- In Section 3, methodologies and structures used in a CMSS-based mission are comprehensively described, providing insights into its design, organization, and comparative advantages. This section is organized into several sub-sections, each dedicated to a different aspect of the mission, for example:
- Section 3.1 introduces a mission-representative example, serving as a proof of concept for the CMSS.
- Section 3.2 analyzes how data are structured and managed in the mission example, representing the first methodology applied within the CMSS framework.
- Section 3.3 focuses on breaking down the mission content into themes or components, illustrating the second methodology in the CMSS approach.
- Section 3.4 delves into the specific algorithms or processes used in designing the mission within the CMSS, highlighting the third methodology used.
- Section 3.5 explores the goal-oriented aspects of the mission design, discussing how the mission’s objectives are structured and achieved, representing the fourth methodology.
- Section 3.6 describes a unique approach where thematic elements are prioritized over geographical or spatial considerations in mission planning, indicative of the fifth methodology in the CMSS.
- Section 3.7 provides a comparative analysis of the CMSS with other existing systems or methodologies in the domain, highlighting its uniqueness and advantages.
- In Section 4, a detailed discussion explores various aspects of enhancing decision-making systems:
- Section 4.1 emphasizes the importance of high-quality input in DSSs, CMSSs, and ISs.
- Section 4.2 highlights the critical role and necessity of developing these systems.
- Section 4.3 shifts focus to the efficient enhancement of data and procedural organization within these systems.
- Section 4.4 examines the potential limitations and challenges associated with the proposed CMSS in depth.
- Section 4.5 discusses practical considerations for implementing the CMSS framework in real-world applications.
- Section 4.6 explores future perspectives and emerging trends in CMSS.
- Section 4.7 explores the uncertainty in large-scale datasets and the role of fuzzy and interval data in enhancing DSSs.
- In Section 5, the conclusions of the present work are stated.
- This study is accompanied by Appendix A, Appendix B, Appendix C, Appendix D and Appendix E that offer detailed insights into various facets of the subject matter (e.g., organization and structuring of data within an IS, development and architecture of algorithms used in designing missions, mathematical equations, formulas, relationships, and expressions that enhance the understanding of the examined approaches, etc.)
- Lastly, a list of the references and relevant bibliographies used in the present study is given.
2. Materials and Methods
2.1. Identification of Input Data Requirements and Internal Frameworks for the Development of CMSSs
2.2. Input Information Requirements in CMSSs for Operational Specialists to Successfully Execute Complex Missions
- The common information. It is the type of information which usually satisfies common needs and operational requirements of mission actors. The most characteristic aspects of this information are presented below:
- Specialized information satisfies the special (particular) needs of actors not only to obtain a satisfactory real-time situational awareness, which is the ability to perceive, understand, and effectively respond to an unexpected situation in an operational field, but also to be capable of acting appropriately with precision and time exactness, maximizing the probability of mission success. A characteristic specialized example is the specialized information required during any Search and Rescue (SAR) mission concerning an aircraft pilot. SAR missions require, among others, (a) information regarding the aircraft type, accident location, time of incident, flight trajectory towards the critical crash area, etc., (b) pilot-related information covering pilot identity, equipment, potential pilot responsibility for the aircraft’s crash, current pilot status, etc., (c) environmental details regarding terrestrial or aquatic conditions, present and future weather conditions at low altitudes, potential obstacles or hindrances for search and rescue operations, etc., (d) authorities’ response details encompassing the availability of agencies for SAR, their operational capabilities, resource availability, equipment, materials, search and rescue personnel required, etc.
2.3. Addressing Technical Difficulties in Managing Large-Scale Input Datasets within ISs
- Serious structural complexity and complicated interconnections among their components [40].
- Substantial diversity in their configuration, encompassing various definitions, contents, forms, and formats [41].
- Highly increased thematic diversity due to numerous of additional actors and heterogeneous procedures [42].
- Most importantly, a notable degree of polymorphism, indicating variability in how data are defined and their content across different versions. These versions are tailored to meet specific purposes for which the data are used [43].
2.4. Distinctive Traits of SSs—Difficulties Involved in Their Design
2.5. Systematic Development of Organized and Sustainable Data Cores—Dissemination of Information
2.5.1. Information Organization of the Incoming Data in DSSs, Based on Mission Purposes (1st Methodology)
2.5.2. Thematic Decomposition of Complex Operational Procedures (2nd Methodology)
2.5.3. Input Data Organization within IS Solution for IT Engineering Challenges
- Step 1: Enter thematic information in the system and classify it according to mission objectives and purposes.
- Step 2: Categorize information by theme, time, and geographic relevance aligning with the operational requirements of the mandatory expert data and input information (with thematic content) into the system (referred to as thematic directory list of information).
- Step 3: Seek additional operational information essential to support the mission’s primary goals promptly and accurately.
- Step 4: If required information is inaccessible, explore alternative information sources that could indirectly aid in assessing the current situation and support mission purposes.
- Step 5: Upon identifying available information enabling rational conclusions, source this information from appropriate channels.
- Step 6: In cases where no relevant information is available, revisit the directory list of information and adjust the mission’s objectives to locate pertinent existing information facilitating an equivalent assessment.
- Step 7: In cases where finding equivalent information proves impossible, iterate through the process of adjusting the mission’s objectives to discover preexisting relevant information leading to an equivalent assessment and support mission purposes.
- Step 8: If the effort of adjusting fails to yield the desired equivalent results, revisit the list of information (directory) and further adapt the mission’s objectives to retrieve information with satisfactory assessment for supporting the mission purposes.
- Step 9: Repeat this algorithmic procedure iteratively until sufficient assessments for the mission are achieved.
2.5.4. Mission Design Algorithm for Identifying Key Intermediate Objectives for CMSS (3rd Methodology)
- The purpose for which these procedures are performed varies according to each involved actionable actor.
- The definition and form, or the content of each operational procedure, differ among different actionable actors.
- Step 1: Creation of a list of fundamental mission segmentsIn the mission design phase, each mission is divided into fundamental mission segments to ensure functional and operational manageability, employing appropriately selected segment lengths. This technique, known in engineering terminology as “divide and conquer”, allows for effective thematic mission sub-divisions [53]. It is crucial for each sub-division to account for any temporal or spatial constraints that might influence the lengths of these fundamental segments.
- Step 2: Creation of a list of points of interestPoints of Interest (POIs) are defined within each fundamental mission segment for operational planning reasons because their completion leads to the success of the mission. POIs are preplanned and considered of high priority because of the necessity for specialized handling and specific operational scrutiny during mission design and execution. POIs are selected at the discretion of the officials of the plan and are primarily map related; however, they might also encompass the concept of time or carry a logical interpretation and usefulness. These POIs necessitate the investigation of operational procedures, e.g., communication, mission criteria, conditions, situational awareness, record log files, etc. The number of POIs depends on the operation designer executive’s capability to decide with operational accuracy in order to achieve successful mission completion. In a sense, POIs can also be referred to as transition nodes. Before and upon them, the appropriate operational actions should be executed effectively throughout the mission. These actions are related to the mission’s success status, namely the total completion of the mission, the possibility of partial failure, and the potential abortion of the mission if demanded by the circumstances.
- Step 3: Creation of a list of fundamental mission segments with their POIs.This list is created by the outcomes of step 1 and step 2.
- Step 4: Creation of two iterative procedures, defined as external and internal loops.The use of the fundamental mission segments and POIs leads to a novel algorithm characterized by two iterative procedures, one of which (referred as internal, “In”) is nested within the other (referred as external, “Ex”):
- The external iterative procedure (Ex-loop) involves transitioning from the beginning of each fundamental mission segment to the beginning of the next.
- The internal iterative procedure (In-loop), nested within the external iterative procedure, involves transitioning from one POI to another within each fundamental mission segment.
The aforementioned iterative procedures are capable of describing any objective, intermediate or not, due to their exceptionally high generality. This characteristic strongly implies that the algorithmic process itself is inherently generalized. - Step 5: Execution of the mission design algorithm methodology inside the CMSS.The documentation of a mission construction design algorithm encompassing the transition from the external to internal iterative procedure is described in pseudocode based on C# (see Appendix D for further details).Additionally, in Appendix D, a detailed analysis of the algorithmic complexity of the pseudocode that was implemented by the previously described methodology is presented. The time complexity of this algorithm is estimated to be O(n2), and the space complexity is O(n2). These complexities are based on the selected data structures deemed optimal for each step of the algorithm.
2.5.5. Use of the Teleological Architecture for Organizing Systems (4th Methodology)
Thematic (Mission) Decomposition of Teleological Architecture
Data/Indicators Cores and Computational Methods of Teleological Architecture
Exemplary Architecture of a System with Teleological Organization
Methodology for Bringing Order within Systems Based on Teleological Architecture
- Step 1: Identify, at the highest possible level, important missions or complex operational procedures which a supporting system can substantially support.
- Step 2: Assign priorities to the identified missions or complex operational procedures. If necessary, restrict the selection of missions according to technical, financial, or any other necessary criteria and select the missions which can be supported.The previous two steps are common at any level of command (e.g., national, strategic, and operational).
- Step 3: For each remaining mission or set of complex operational procedures, start recursive decomposition into simpler sub-missions (or sub-procedures). Gradually, a tree-like structure is created that looks like an acyclic graph. This graph comprises many levels depending on the number of sub-missions which have been created. Every sub-mission is well-defined, detailed, and simpler than the layer above. Stop the decomposition at sub-missions that: (i) can no longer be divided into simpler ones. We shall call these sub-missions fundamental. In the tree-like structure, each fundamental sub-mission appears as leaf; (ii) have an unambiguous description of their input (data), methodology of computation (methods or programs), and output. This output consists of indicators which are the data that permit decision making.
- Step 4: For each one of the fundamental sub-missions, specific data input will be needed for the SS. These input data are completely specified by the necessary indicators. Practice has shown that it is necessary to completely define the following:
- The exact form and format, as well as the necessary characteristics, of these data, according to their intended use.
- The sources from which these data have to be acquired.
- Any necessary procedures for cleansing, filtering, transformation, or merging of the acquired input data, so that the needed data can be computed. This sub-step may have a very wide range of difficulty.
- Exact procedures for regular and timely updating of the data.
- Step 5: If data gaps remain, then:
- First, examine if there is a way to directly compute the missing data from other available data.
- Then, examine if there are any other available data from which it is easy to make good-quality estimations for covering the gaps of missing data.
- If good-quality estimations cannot be found, look for sub-missions similar to the fundamental ones (as defined in step 3), which may involve different indicators, computed from data, for which good-quality estimations can be obtained.
- Otherwise, try to collect new input data.
- Step 6: In the case that data gaps still remain after steps 4 and 5, try to further back-track in the tree-like structure of the decomposed missions for a sub-mission that can be modified so that, eventually, computable indicators can be found, without compromising the actual aims of the mission.In a considerable number of cases, this back-tracking may involve going several levels up, and actually redesign a part of the mission, until all data needs are satisfied.
- Step 7: From the list of the fundamental sub-missions of the initial mission, create:
- a total indicators list,
- a total list of the computational methods (program list),
- a total data list, which is used as input to the computational methods to produce indicators), and
- a total list of updating procedures, in order to regularly and timely update the data cores of the system.
- Step 8: Organize all the information produced so far in a composite, advanced database, which is governed by a meta-database of critical importance, named a teleological structure. The prior algorithmic process mandates that all generated descriptions be systematically arranged within the teleological meta-database. Meanwhile, all remaining data must find their place within the composite database.
Use of Organization of Geodata Called “Themes over Maps”, Based on Teleological Structure (5th Methodology)
3. Results
- The first sub-system (noted as “a” in Figure 11) concerns the preprocessing stage aiming at preparing to organize the input data before they enter the system that will support any mission and has a relationship with methodology “1” because it fixes the anarchic and disordered data input in the system.
- The second sub-system (noted as “b” in Figure 11) concerns the stage after the data preprocessing stage. In this phase, the preprocessed dataset undergoes more specialized organization based on a way of organizing data related to actionable actors’ needs. This phase has a relationship with methodology “5” (“themes over maps”).
3.1. Representative Mission Example: Proof of Concept (PoC) in CMSS
3.2. Data Organization in Representative Mission Example (PoC in CMSS): 1st Meth
- Mission overview: objective “1”—transport of classified documents from point “1” to “3” with a police vehicle (actor “1”) and objective “2”—transport of a patient from point “1” to “2” with an ambulance (actor “2”).
- Step-by-step application of algorithmic process for classification.
- Step 1: Enter thematic information in the system, i.e., objective “1”—classified document transportation, classify under theme “security for documents”; objective “2”—patient transportation, classify under theme “medical emergency for the patient”.
- Step 2: Categorize information by inputting in the system and creating thematic directories. For the present representative mission, an example could be security and medical, immediate transport requirement, potential delays, geographic points “1”, “2”, “3”, assess routes and distances, etc.
- Step 3: Seek additional operational information, i.e., traffic conditions, route security, medical facilities en route, availability of resources: police and medical personnel, etc.
- Step 4: Explore alternative information sources, i.e., if route information is lacking, check local news, traffic apps, community alerts, etc. If direct contact with a hospital is impossible, check regional health databases, etc.
- Step 5: Source information from appropriate channels, i.e., use police networks for security information, hospital records, and emergency services for medical information, etc.
- Step 6: Adjust mission objectives if necessary, i.e., if certain routes are blocked or unsafe consider alternative paths, if the nearest hospital is not available find the next closest one.
- Step 7 (if step 6 does not work): Iterate to find equivalent information, i.e., reevaluate routes and available facilities to find new information based on real-time input data.
- Step 8 (if step 7 does not work): Adapt mission’s objectives further, i.e., if continuous obstacles arise, try to adapt the mission’s objectives based on urgency and time constraints. Prioritize one of the two missions based on the aforementioned criteria and consider additional criteria such as the departure and arrival times, resource allocation, etc.
- Step 9: Repeat iteratively (i.e., go to step 1), namely, reassess mission objectives, ensuring that each adjustment brings the mission closer to an achievable outcome, by simultaneously correlating the information needed to the adjusted mission objectives.
3.3. Thematic Decomposition in Representative Mission Example (PoC in CMSS): 2nd Meth
- Clarity: By splitting the mission into two sub-missions (point “1” to “3” for document transport, and point “1” to “2” for patient transport) each team—the police and the ambulance crew, respectively—has a clear understanding of their distinct objectives. This clarity ensures that each actor knows his route, his cargo (i.e., classified documents or a patient), and specific operational requirements.
- Efficiency: Resources can be allocated specifically for each sub-mission. The police vehicle used for the documents can be equipped accordingly for security, while the ambulance can be equipped with medical supplies. Independent tackling of each sub-mission prevents resource overlap and ensures that each mission is carried out with the appropriate means and actors.
- Risk assessment: Operating the two sub-missions separately allows for a more focused risk analysis. For the police vehicle, the primary risks might involve security threats, whereas for the ambulance, the primary risks are related to medical emergencies en route. This separation allows each team to prepare for and mitigate their specific risks effectively.
- Communication: Clear communication channels can be established for each sub-mission. The police team will have a dedicated communication line focused on route security, while the ambulance crew will maintain communication with medical personnel. This prevents communication misunderstadings and ensures that each team receives the information needed.
- Resource optimization: Resources, e.g., fuel, personnel, equipment, etc., are allocated precisely according to the needs of each sub-mission. The police vehicle might require additional security personnel en route, while the ambulance may need medical staff (communicating remotely with the medical center of operations) and equipment (from local health centers). This targeted allocation prevents resource waste.
- Quality control: The flow of input information contributes to quality control for each thematic sub-mission, e.g., document transport might require assurance for the security of the information, while patient transport involves maintaining high medical care standards.
- Adaptability: If, for example, there is a traffic jam en route to the hospital, the ambulance can adapt its route independently without affecting the document transportation. Eventually, the existence of two distinct sub-missions ensures that changes in one sub-mission do not unnecessarily complicate or delay the other.
- Problem isolation: If the police vehicle encounters a problem, such as a mechanical failure, it can be addressed without directly impacting the patient transportation. This isolation of problems prevents a domino effect, ensuring that a problem in one area does not escalate to affect the other sub-mission.
3.4. Mission Design Algorithm in Representative Mission Example (PoC in CMSS): 3rd Meth
- The creation of a list of fundamental mission segments. The mission is divided into two primary segments: segment “a” which concerns the transport of classified documents from point “1” to “3” (by police vehicle, actor “1”) and segment “b” which is the transport of a patient from point “1” to “2” (by ambulance, actor “2”). Each segment is independently manageable and designed considering the unique requirements of its cargo transportation.
- The creation of a list of Points of Interest (POIs). For segment “a” (document transport), potential POIs could include traffic lights or secure checkpoints, areas of high traffic, locations requiring specific navigation strategies, etc. For segment “b” (patient transport), potential POIs might include a tunnel or local health centers, where the ambulance is forced to make a short stop over due to the patient’s condition, the fastest routes for emergency transport by-pass, etc. In both cases, POIs are selected based on the urgency, security needs, and operational complexities of each transport mission.
- The creation of a list of fundamental mission segments (with their POIs). The representative mission example segments are combined with their respective POIs, as follows: (a) path of segment “a” from point “1” to “3” with its POI “1”, which is a traffic light, (b) path of segment “b” from point “1” to “2” with its POI “2”, which is a tunnel.
- The creation of two iterative procedures (external and internal loops). The external loop (Ex-loop) could involve transitioning from the preparation phase at point “1” to the execution of segments “a” and “b”. This loop involves two repetitions, one for each segment. The internal loop (In-loop) could involve, for segment “a”, transitioning between POIs from point “1” to “3” and, for segment “b”, transitioning between POIs from point “1” to “2”. For each segment scanned through the external loop, this internal loop involves as many repetitions as the number of POIs along the segment’s path. In the case considered in this study, for each segment the inner loop contains a single repetition for the one POI shown in Figure 13. These loops facilitate the operational flow of the mission, ensuring that all necessary actions are taken at each POI.
- The execution of the mission design algorithm methodology in the CMSS. The algorithm for the transport representative mission example is totally documented and executed in a CMS system. This includes the specifics of handling each type of cargo (e.g., classified documents and a patient), the different transport vehicles (e.g., police vehicle and ambulance), and any other logistical or operational requirements.
- The benefits for specialist actors include the structured operational approach to complex missions. The algorithm breaks down complex missions into manageable segments by including Points of Interest (POIs). This approach provides operational versatility to actors to understand and effectively execute their missions. Moreover, clarity in operational roles and responsibilities is provided by identifying key intermediate objectives, and each actor knows their specific role at every stage of the mission, reducing confusion and increasing efficiency. Furthermore, enhanced decision making due to the predesigned, well-defined POIs and mission segments aids actors to make decisions, especially in dynamic and rapidly changing situations. Lastly, risk mitigation is achieved, since the algorithm allows planning for the potential risks and threats, enhancing the safety and probability of the success of the mission. Last, but not least, flexibility in real-time adjustments is possible since the iterative nature of the algorithm allows for adjustments in response to unforeseen circumstances, even though the mission is preplanned.
- The benefits from a design engineer’s standpoint include the modularity and scalability, due to the algorithm’s divide and conquer approach which means that it can be adapted to various mission complexities, enhancing the system’s scalability. Secondly, data management and analysis are feasible because the systematic breakdown of the mission aids in avoiding information overloading via a targeted data requirement pertinent to actionable actors. The results of data organization and dissemination could be used as benchmarks for the SS’s architecture design. Thirdly, the minimized computational overhead is achievable because the algorithm may efficiently handle complex procedures due to the use of nested loops (external and internal). Moreover, enhanced communication and coordination due to the compartmentalization of mission segments and POIs facilitate the design engineer to minimize the computational load related to the communication and coordination procedures in the SS. Finally, the CMSS provides a framework which allows for smoother operational transitions from one system to another. Thus, the integration with existing systems could be easier than before.
3.5. Teleological Structure in Representative Mission Example (PoC in CMSS): 4th Meth
- Meth. “1” is interconnected to “4” since the organization of input data in the teleology structure aligns with meth. “1”, considering the way the human mind works.
- Meth. “2” is interconnected to “4” because the thematic decomposition in the teleology structure inspired by the “divide and conquer” algorithm is very similar to the creation of segments by the human mind in an abstract way for assigning tasks in a narrow range field.
3.6. “Themes over Maps” Structure in Representative Mission Example (PoC in CMSS): 5th Meth
- There are two main actionable actors, i.e., a police vehicle transporting classified documents (actor “1”) and an ambulance transporting a patient (actor “2”). Each actor has specific needs and roles within the mission.
- Additionally, the specialized database consists of common and specialized information. For the police vehicle (actor “1”), specialized information might include the best route to avoid traffic and maintain security, communication protocols, potential threats along the route, legal considerations for carrying classified documents, etc. For the ambulance (actor “2”), specialized information might include the fastest route to the hospital, medical facilities available en route in case of emergency, traffic conditions, patient-specific medical information, etc.
- Furthermore, methodology “5” (“themes over maps”) is applied by mapping out each sub-mission with relevant themes, e.g., for actor “1”, common information could be security protocols, route integrity, communication channels, etc. and for actor “2”, common information might be medical support, route efficiency, emergency protocols, etc.
- It is worth mentioning that the application of the “need to know” principle provides information access and control. Namely, each actionable actor has access only to the information needed for satisfying the specific purposes of their part of the mission. This ensures efficient and precise communication with a reduced risk of information overload or irrelevant input data interfering with mission objectives and enhanced operational efficiency.
- Finally, the association between the operational procedures and the information required for actors to execute their mission, e.g., the police vehicle’s driver is obliged to execute a set of operational procedures/processes, which might be a checklist of security measures, while the ambulance crew is obliged to execute a set of operational procedures/processes, which might be protocols for patient care and emergency health response.
3.7. Comparative Analysis of Proposed CMSS with Other Related Works/Existing DS System Methodologies
4. Discussion
4.1. Enhancing Decision-Making Systems: Overcoming the Garbage In, Garbage Out (GIGO) Problem
4.2. The Necessity of DSS/CMSS and IS Development
4.3. Efficiently Enhancing the Data and Procedure Organization in DSSs, CMSSs, and ISs
4.4. Potential Limitations and Challenges Associated with Proposed CMSS
4.5. Considerations for Implementing CMSS Framework in Real-World Applications
4.6. Future Perspectives and Emerging Trends in CMSS
4.7. Uncertainty in Large-Scale Datasets—The Role of Fuzzy and Interval Data in Enhancing DSSs
5. Conclusions
Supplementary Materials
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
Appendix A
Number | Description | Category |
---|---|---|
1 | Scheduled transportation of explosive materials for use in quarries. | Hazardous Material Transport |
2 | Aerial spraying in various areas in cultivated, forested areas, fields, or even inhabited regions. | Environmental Management |
3 | Scheduled money transport from mainland to island areas. | Secure Transport |
4 | Fleet route management, traffic flow analysis, and ad hoc, optimal routes. | Logistics/Transport Management |
5 | Incident management for a truck carrying hazardous materials and toxic chemicals (or hazardous biological or radiological substances) near cultivable agricultural or residential areas. | Emergency Response/Hazardous Incident |
6 | Management of fire incident or bus accidents in a tunnel requiring medical intervention. | Emergency Response/Accident Management |
7 | Handling helicopter (civilian or military) crashes in mountainous regions or international waters during extreme environmental conditions. | Search and Rescue/Emergency Response |
8 | Handling a maritime accident involving mechanical damage of a passenger ship. | Maritime Incident Management |
9 | Incident management for a power outage due to a fire at an electrical substation. | Emergency Response/Infrastructure |
10 | Managing a severe traffic accident and urgent transportation of injured people to a hospital. | Emergency Response/Accident Management |
11 | Air piracy and forced landing. | Aviation Security/Emergency Response |
12 | Crisis management for heavy rainfall, flooding, and extreme natural events. | Disaster Management |
13 | Maritime piracy on a commercial ship and movement of the captured ship in a national or international sea area. | Maritime Security |
14 | Catastrophic event or sabotage against energy facilities on the mainland (i.e., natural gas pipelines) or in the sea (i.e., oil-drilling platforms). | Infrastructure Security/Disaster Management |
15 | Ecological disaster due to an oil spill from a tanker. | Environmental Crisis/Emergency Response |
16 | Catastrophic events in extreme weather conditions requiring vehicle movement in rough terrain. | Disaster Management/Emergency Response |
17 | Urgent transport of a vital organ for transplant across countries. | Medical Emergency Transport |
18 | Multi-national operations against terrorism. | Counter-Terrorism |
19 | International cybersecurity operations. | Cybersecurity/Intelligence |
20 | Emergency evacuation plan implementation for an inhabited area. | Emergency Management and Public Safety |
21 | AI-powered attack on the electrical grid of a country. | Counter-Measure Operations Planning |
Appendix B
- Athanasios Panagopoulos, Operational Officer and Intelligence Specialist.
- Theodoros Papageorgiou, Operational Officer in Special Forces, Specialist in NATO Operational Procedures and Military Decision-Making Process Systems.
- Evangelos Iordanopoulos, Navy Officer, Security Specialist in Port Infrastructures.
- Chris Mavromatis, Expert in Transport Missions of VIPs and Transportation of Hazardous Cargo.
- Information related to an area/location are typically described using coordinates such as geographic latitude, geographic longitude, altitude on specific reference plane, etc. This level may vary depending on the region. For instance, terrestrial locations commonly reference sea level, while marine data typically employ the maximum water level. When information originates from different sources, it may be necessary to harmonize (make interoperable) the data before their use.
- Information related to transportation networks, e.g., roads, railways, air and sea lines, ports, airports, freight and passenger stations, vehicle, ship, and airplane routes, etc. There is a need for representing and visualizing this information according to mission requirements on different scales, i.e., buildings (underground parking spaces), special intersections, environmental areas, limited or wider urban areas, main roads of a metropolitan area or a significant city region, highways or equivalent network links of other transportation means, etc.
- Information related to weather (static or dynamic), e.g., locations prone to flooding, areas of heavy rainfall, areas of passing storms, strong winds, etc. This information is often correlated with 2D maps, limited to surface-level weather impacts. Under certain circumstances, 3D maps could be provided. They demand significantly greater storage capacity and computational capability. This increases the complexity of control but offers the ability to visualize a bigger context of information.
- Information related to morphological terrain characteristics, e.g., areas of vegetation, forests, gorges, flooded terrain, ongoing wildfires (dynamic information), etc. Usually, this information is 2D, associated with appropriate projections of 3D space on 2D maps.
- Any additional information related to entities, associated with a map, i.e., elements of transportation networks, infrastructures, buildings, infrastructure projects, airports, ports, industrial zones, residential areas, military bases, campsites, road intersections, tunnels, bridges, stations, etc. In this case, as well, the necessary scales for data needed may vary significantly, even for the same mission, greatly increasing the difficulty in handling the respective data.
- Example of transportation of medical transplant. Organizing a medical transplant mission is a complex process that requires detailed planning and coordination. Key information includes understanding the specific type of medical transplant, as each type has unique procedures and handling requirements. Equally important is assessing the health status of the donor to ensure the transplant’s suitability. Information about the recipient’s medical condition is crucial for compatibility and to evaluate potential rejection risks. Additionally, the storage and transportation of the transplant material must meet specific requirements to preserve its viability. Finally, compliance with legal regulations governing transplant transportation is as critical as the medical aspects of the process, underscoring the multifaceted nature of organizing a successful medical transplant mission.
- Example of transportation of hazardous cargo (from one location to another). This type of mission, involving the transportation of hazardous cargo, is inherently high risk and necessitates stringent safety measures. It requires comprehensive information on various aspects: Firstly, the nature of the hazardous cargo—gas, liquid, or solid—each with its unique safety standards and handling protocols. Secondly, the choice of transportation mode is crucial, whether it be by sea, air, road, convoy, or rail. Thirdly, adherence to the specific legislation of each country involved is mandatory, including transport permissions and compliance with transport regulations. Fourthly, a detailed focus on safety requirements is essential, encompassing the selection of suitable transport methods, thorough inspection of intermediate transit stations, and, if necessary, evacuation of certain areas. Lastly, the training of personnel is paramount; they must be well-versed in handling procedures, experienced in emergency response, and familiar with real-life accident scenarios.
Appendix C
Algorithm A1: Pseudocode of algorithm for data organization |
// Define a class to represent thematic information class ThematicInformation { // Properties for thematic content string Theme; string Time; string GeographicRelevance; // Other relevant properties } // Step 1: Entering thematic information and classifying it void EnterAndClassifyThematicInformation(List<ThematicInformation> thematicData) { // Perform classification based on mission objectives and intentions } // Step 2: Categorizing information aligning with operational requirements List<ThematicInformation> CategorizeInformation(List<ThematicInformation> thematicData) { // Categorize by theme, time, and geographic relevance // Align with operational requirements // Output thematic directory list of information return categorizedData; } // Step 3: Seeking additional operational information void SeekAdditionalInformation() { // Seek operational information to support mission goals } // Step 4: Exploring alternative information sources void ExploreAlternativeSources() { // Attempt to find indirect information sources } // Step 5: Identifying available information enabling rational conclusions void IdentifyAvailableInformation() { // Source information from appropriate channels } // Steps 6–8: Adjusting mission objectives and revisiting directory list void AdjustMissionObjectives() { // Revisit directory list, adjust mission objectives } // Step 9: Iterative procedure for sufficient assessments void IterativeProcedure() { // Perform iterative process until sufficient assessments achieved} |
- Algorithmic complexity. A mathematical discipline that assesses the time and space requirements of various algorithms and data structures. It establishes an essential foundation for understanding the impact on efficiency and performance resulting from algorithmic decisions in software development. Developers can enhance their code for speed and memory efficiency by analyzing its complexity, guaranteeing efficient scalability as data size or computational needs increase. This is particularly important in the implementation of the methodologies inside the CMSS, as it is important that the system can scale without setbacks with the accumulation of ever more input data.
- Temporal complexity. The computational time an algorithm needs to finish a task, based on the size of the input, is known as time complexity. It determines the maximum amount of time that is required and forecasts how an algorithm’s execution time will change as the volume of input data increases. When characterizing an algorithm’s time complexity, Big O notation is used to highlight the worst-case scenario by indicating the maximum running time.
- Spatial complexity. The amount of memory required by an algorithm to complete a task in relation to the size of the input is measured by space complexity. This is the total amount of space that the input data takes up plus any additional space that the process uses, like stack space and temporary variables. Like temporal complexity, space complexity helps explain how an algorithm’s memory consumption rises as the size of the input increases.
- Ω (omega) complexity. The shortest algorithmic runtime that can be achieved is called omega complexity. The phrase describes the shortest amount of time, independent of input volume, needed for an algorithm to complete its execution. When an approach uses omega notation, it means that its optimal performance will not exceed a given time limit.
- Θ (theta) complexity. An algorithm’s upper and lower temporal complexity can be expressed using theta complexity. Within the well-defined bounds of Θ notation, the algorithm’s execution time grows linearly with increasing input size, providing a distinct limit. When the performance of the algorithm is consistently predictable, it refers to the average-case scenario.
- O (big O) complexity. The longest time an algorithm takes to execute in the worst-case scenario is known as big O complexity. This method shows how the execution time increases with larger data inputs and sets a maximum time limit for completion. To predict the maximum amount of time an algorithm will take to run, regardless of the size of the input, one must understand O notation.
# Step | Step Operation | Data Structure(s) or Algoritm | Ω Complexity | Θ Complexity | O Complexity | Space Complexity |
---|---|---|---|---|---|---|
1 | Entering and Classifying Information | Hash Table | Ω(n) | Θ(n) | O(n) | O(n) |
2 | Categorizing Information | Hash Table | Ω(n) | Θ(n) | O(n) | O(n) |
3 | Seeking Additional Operational Information | Array | Ω(1) | Θ(1) | O(1) | O(n) |
4 | Exploring Alternative Information Sources | Array | Ω(1) | Θ(1) | O(1) | O(n) |
5 | Identifying Available Information | Array | Ω(1) | Θ(1) | O(1) | O(n) |
6 | Adjusting Mission Objectives | Array or Hash Table | Ω(1) | Θ(1) | O(1) | O(n) |
7 | Revisiting Directory List | Array | Ω(1) | Θ(1) | O(1) | O(n) |
8 | Adjusting Based on Revisited Information | Array or Hash Table | Ω(1) | Θ(1) | O(1) | O(n) |
9 | Iterative Procedure | Balanced Binary Search Tree | Ω(log n) | Θ(log n) | O(n log n) | O(n |
Total | Overall Complexity | - | Ω(log n) | Θ(log n) | O(n log n) | O(n) |
- Step 1: Entering and Classifying InformationWhy This Step: This phase is crucial as it requires categorizing each item of information by processing it just once.Choice of Data Structure: Hash tables are chosen for their efficient insertion and retrieval abilities, making them perfect for organizing and storing distinct information.Complexity Reasoning: Time complexity analysis shows that the algorithm has a linear time complexity of O(n) as each item is processed once. Hash table operations are generally constant in time but may become linear in worst-case scenarios caused by collisions.
- Step 2: Categorizing InformationWhy This Step: Categorizing information by evaluating each item once and assigning it to a certain category.Choice of Data Structure: Hash tables are used to organize and access data efficiently by associating them with unique keys, such as category identifiers.Complexity Reasoning: The process is intricate since each item must be processed once, leading to a temporal complexity of O(n) for entering all things into the hash table.
- Step 3: Seeking Additional Operational InformationWhy This Step: This phase involves obtaining certain operational information often through a single retrieval step.Choice of Data Structure: Arrays are an efficient data structure enabling rapid access to specific information through predetermined indices.Complexity Reasoning: Accessing an element from an array has a time complexity of Θ(1) due to its simple and constant nature.
- Step 4: Exploring Alternative Information SourcesWhy This Step: This phase is essential as it requires either a single lookup or accessing alternative sources.Choice of Data Structure: Arrays are selected for their simple storage and easy access to a collection of elements.Complexity Reasoning: Complexity arises when there is a need to quickly obtain or confirm the existence of an item, especially if the index is known.
- Step 5: Identifying Available InformationWhy This Step: This step probably requires accessing a certain collection of information sources just one time.Choice of Data Structure: Arrays are ideal for storing and accessing a group of data sources in a sequential manner.Complexity Reasoning: Accessing an element in an array directly by index has a time complexity of Θ(1).
- Step 6: Adjusting Mission ObjectivesWhy This Step: Decisions are typically made by considering up-to-date information and are often made through a single decision-making procedure.Choice of Data Structure: The selection of a data structure is based on the requirement for fast access either by key (hash table) or by index/order (array).Complexity Reasoning: The operation of modifying or retrieving data requires a fixed amount of time, independent of the data structure’s size.
- Step 7: Revisiting Directory ListWhy This Step: This indicates a solitary action of revisiting or examining the list, potentially to make a decision or obtain data.Choice of Data Structure: Arrays are suitable for reviewing stored objects since they provide sequential access.Complexity Reasoning: Accessing or iterating through an array to review entries is considered a constant time operation for a single access due to its complexity.
- Step 8: Adjusting Based on Revisited InformationWhy This Step: Involves modifying decisions based on information that has been previously reviewed or revisited, typically involving a single update or choice.Choice of Data Structure: Choose between an array or hash table based on whether the adjustment is related to an order or specific key-based access.Complexity Reasoning: Executing a single modification or choice requires a consistent amount of time, denoted as Θ(1).
- Step 9: Iterative ProcedureWhy This Step: Each iteration requires a logarithmic number of steps because of the operations performed in a balanced binary search tree.Why Balanced Binary Search Tree: Balanced binary search tree is chosen for its efficiency in sorting and retrieval activities that scale logarithmically with the number of items.Complexity Reasoning: Complexity arises from the fact that insertion, deletion, and search operations in a balanced binary search tree have a logarithmic time complexity. However, the worst-case scenario of O(n log n) takes into account repeated actions on all items.
- Total Overall Complexity
Appendix D
Algorithm A2: Pseudocode of diagrammatic mission design algorithm | |
// Define the objects/classes to be used in the Algorithm // Define the class/object: Fundamental Mission Segments (FMSs) [or simply Segments], and its properties { // Define the Unique Identifier for each FMSs long Id; // Create a list of Points of Interest (POIs) belonging to each FMS List<PointOfInterest> PointOfInterests; } // Define the class/object: POIs, and define its properties { // Define the Unique Identifier for each unique POI long Id; } // Create a list of new objects/classes using FMSs and their POIs List<Segment> Segments; // Start External Iterative Process (Ex-Loop) For Each Segment in Segments { // Record Procedures Log Log(); // Operational Procedures Operational Procedures(); // Load Next Segments LoadNextSegments(); // Start Internal Iterative Process (In-Loop) For Each PointOfInterest in Segment.PointOfInterests { // Communication Procedures for Situational Awareness result = Communicate() && SituationalAwarness(); // Actions based on the result of Communication for Situational Awareness If Result = Redirect // 1st Case: Change of Route { Log(); // Record Procedures Log Communicate(); // Procedures related to Communication Redirect(); // Procedures for for Changing Route } Else If Result = TimeStall // 2nd Case: Time Lag (Delay) { Actions(); // Operational Procedures Communicate(); // Procedures related to Communication Log(); // Record Procedures Log } Else // 3rd Case: No time or spatial changes Log(); // Record Procedures Log } // Record Procedures Log Log(); } |
# Step | Operation/Process | Data Structure(s) or Algorithm | Ω Complexity | Θ Complexity | O Complexity | Space Complexity |
---|---|---|---|---|---|---|
1 | Creating FMS Objects | List of n Segments | Ω(n) | Θ(n) | O(n) | O(n) |
2 | Adding POIs to FMS | List of m POIs in n Segments | Ω(1) | Θ(1) | O(1) | O(m × n) |
3 | External Loop over Segments | List (n Segments) | Ω(n) | Θ(n) | O(n) | O(1) |
4 | Log Procedure (Ex-Loop) | Logging Mechanism (File or Memory) | Ω(1) | Θ(1) | O(1) | O(1) |
5 | Operational Procedures (Ex-Loop) | Procedural Algorithm | Ω(1) | Θ(1) | O(1) | O(1) |
6 | Load Next Segments (Ex-Loop) | Queue for Segments | Ω(1) | Θ(1) | O(1) | O(n) |
7 | Internal Loop over POIs | List (m POIs in Segment) | Ω(m) | Θ(m) | O(m) | O(1) |
8 | Communication and Situational Awareness (In-Loop) | Procedural Algorithm | Ω(1) | Θ(1) | O(1) | O(1) |
9 | Handling Redirect (Change of Route) (In-Loop) | Procedural Algorithm | Ω(1) | Θ(1) | O(1) | O(1) |
10 | Handling TimeStall (Delay) (In-Loop) | Procedural Algorithm | Ω(1) | Θ(1) | O(1) | O(1) |
11 | Log Procedure (In-Loop) | Logging Mechanism (File or Memory) | Ω(1) | Θ(1) | O(1) | O(1) |
12 | Final Log Procedure (Ex-Loop End) | Logging Mechanism (File or Memory) | Ω(1) | Θ(1) | O(1) | O(1) |
Total | Overall Complexity | - | Ω(n + m) = Ω(max(n,m)) ≈ Ω(n) | Θ(n × m) = Θ(max(n,m)2) ≈ Θ(n2) | O(n × m) = Θ(max(n,m)2) ≈ O (n2) | O(m × n) = Θ(max(n,m)2) ≈ O (n2) |
- Step 1. Creating FMS ObjectsOperation is One Step: Initializing the data structure to store fundamental mission segments.Choice of Data Structure: The list data structure was chosen for its simplicity and capability to dynamically add segments.Complexity Reasoning: Creating each FMS object has a time complexity of O(1), while performing this operation n times results in a time complexity of O(n).
- Step 2. Adding POIs to FMSOperation is One Step: Each Point of Interest (POI) is added individually to its corresponding Fleet Management System (FMS).Choice of Data Structure: Using lists within each segment enables the dynamic addition of POIs.Complexity Reasoning: The addition of a single Point of Interest (POI) has a time complexity of O(1), while the space complexity O(m×n) considers all POIs over all segments.
- Step 3. External Loop over SegmentsOperation is One Step: Processes each segment once during iteration.Choice of Data Structure: A list allows for sequential traversal of elements.Complexity Reasoning: Iterating through all segments once results in a linear time complexity.
- Step 4. Log Procedure (Ex-Loop)Operation is One Step: Records one entry, usually a brief procedure.Choice of Data Structure: Logging to file or memory is efficient for individual entries.Complexity Reasoning: Logging is classified as an operation with constant time complexity, independent of input size.
- Step 5. Operational Procedures (Ex-Loop)Operation is One Step: Carries out predetermined procedures without repetition.Choice of Data Structure: Procedural algorithms operate regardless of the size of the data structure chosen.Complexity Reasoning: These methods often exhibit a constant time complexity since they involve minimal data processing.
- Step 6. Load Next Segments (Ex-Loop)Operation is One Step: Enqueues or dequeues the next segment for processing in a single step.Choice of Data Structure: A queue arranges elements in a First In, First Out (FIFO) order.Complexity Reasoning: Queue operations have a constant time complexity, while the space complexity increases proportionally with the number of segments.
- Step 7. Internal Loop over POIsOperation is One Step: Each Point of Interest (POI) inside a segment is processed one after the other.Choice of Data Structure: A list allows for easy iteration across Points of Interest (POIs).Complexity Reasoning: Iterating over Points of Interest (POIs) in a segment exhibits linear complexity relative to the number of POIs (m).
- Step 8. Communication and Situational Awareness (In-Loop)Operation is One Step: Perform a check or communication for each Point of Interest (POI).Choice of Data Structure: A procedural method designed specifically for the purpose, regardless of the complexity of the data structure.Complexity Reasoning: Each operation is assumed to have a constant time complexity, regardless of the quantity of the data being processed.
- Step 9. Handling Redirect (Change of Route) (In-Loop)Operation is One Step: It modifies the route according to new information for a Point of Interest (POI).Choice of Data Structure: Decision making does not depend on a sophisticated data structure.Complexity Reasoning: The procedure has a constant time complexity, provided that the conditions for redirection can be immediately evaluated.
- Step 10. Handling TimeStall (Delay) (In-Loop)Operation is One Step: Executes a delay or pause based on specific requirements, completing one operation.Choice of Data Structure: Procedural latency is independent of the underlying data structure.Complexity Reasoning: The time complexity of the operation is O(1) due to a fixed or context-specific delay.
- Step 11. Log Procedure (In-Loop)Operation is One Step: Records details related to the In-loop procedures.Choice of Data Structure: Implementing a logging method optimized for fast entry writing.Complexity Reasoning: Constant time complexity is achieved by efficiently logging a single entry.
- Step 12. Final Log Procedure (Ex-Loop End)Operation is One Step: Indicates the conclusion of a loop or a big achievement.Choice of Data Structure: Employs a consistent logging technique.Complexity Reasoning: Remains constant (O(1)) due to being a unique operation at the end of a process.
- Total (Excluding Constant Ops)
Appendix E
- Who will execute the mission (unit or organization),
- What they will do during the mission (tactical mission essential task),
- Where they will operate (area of operations, objective, grid coordinates),
- When the operation will begin (by time or event) or what is the duration of the operation,
- Why will the force conduct the operations (why is the mission necessary), and
- What else could be added as information, known as the rule of:
- i: is the vector/edge of specific indicators,
- f: is the computational method, including mathematical or algorithmic processes, or is a mathematical model or is a complex transfer function, and
- d: is the vector of input data, which is necessary for the calculation of the relevant indicators [25].
- i is the grade of thematic decomposition of initial mission “M0: W(j)” into sub-missions “M(t,a): W(j)”, where t ∈ ℕ*,
- p is the number of participant actionable actor(s) or sub-actor(s), where p ∈ [1, 2, 3,…, n],
- n is the max number of participant actionable actor(s) or sub-actor(s), where n ∈ ℕ*,
- SDC is a special data core, which includes the operational information, and
- j is the maximum number of questions, where j ∈ ℕ*.
def M(x): # Assuming M(x, 1) is defined elsewhere and computes something based on x # For demonstration, let’s say M(x, 1) = x, replace this with the actual function def M_x_1(x): return x # Compute the summation Σ from i = 0 to x of M(i, 1) sum_result = sum(M_x_1(i) for i in range(0, x + 1)) return sum_result # Example usage x = 5 print(f”M(0,1) for x = {x} is: {M(x)}”) |
- p-actors, p ], where n is the max number of actors, n ∈ ℕ*,
- x is the max number of sub-missions of 1 actor, where x ∈ ℕ*,
- k is the max number of sub-missions of 3 actors, where k ∈ ℕ*,
- z is the max number of sub-missions of “n” actors, where z ∈ ℕ*,
- M(0,p) is the initial mission “M0” of each participant p-actor, where p ∈ [a,n].
# Placeholder function for M(i, p) to represent the computation of sub-missions. # Replace this with the actual logic for computing sub-missions. def M(i, p): # Example computation, replace with actual logic return i * p # Compute the summation for a specific actor p over x sub-missions def compute_sum_for_actor(x, p): return sum(M(i, p) for i in range(1, x + 1)) # Overall computation of the mission combining all actors def compute_overall_mission(n, actors_submissions): total_sum = 0 for p in range(1, n + 1): total_sum += compute_sum_for_actor(actors_submissions[p−1], p) return total_sum # Example usage n = 4 # Max number of actors actors_submissions = [5, 7, 3, 8] # Max number of sub-missions for actors 1, 2, 3, …, n respectively overall_mission = compute_overall_mission(n, actors_submissions) print(f”The overall mission computation is: {overall_mission}”) |
References
- Sànchez-Marrè, M. Evolution of Decision Support Systems. In Intelligent Decision Support Systems; Springer International Publishing: Cham, Switzerland, 2022; pp. 57–73. [Google Scholar] [CrossRef]
- Guidry, T.L.; Halligan, B.B.; Peters, C. Strategies for handling failures in development of information systems. J. Manag. Issues 2018, 1, 363–377. Available online: https://www.jstor.org/stable/45176590 (accessed on 24 February 2024).
- Stodola, P.; Mazal, J. Architecture of the Advanced Command and Control System. In Proceedings of the International Conference on Military Technologies (ICMT), Brno, Czech Republic, 31 May–2 June 2017; pp. 340–343. [Google Scholar] [CrossRef]
- Dietz, T.; Klamroth, K.; Kraus, K.; Ruzika, S.; Schäfer, L.E.; Schulze, B.; Stiglmayr, M.; Wiecek, M.M. Introducing multiobjective complex systems. Eur. J. Oper. Res. 2020, 280, 581–596. [Google Scholar] [CrossRef]
- Joseph, N.; Marnewick, C. Measuring information systems project complexity: A structural equation modelling approach. Complexity 2021, 2021, 5907971. [Google Scholar] [CrossRef]
- Alshurideh, M.; Al Kurdi, B.H.; Alzoubi, H.M.; Salloum, S. The Effect of Information Technology on Business and Marketing Intelligence Systems. In Nature; Springer International Publishing: Cham, Switzerland, 2023; Volume 1056, pp. 703–715. [Google Scholar] [CrossRef]
- Keenan, P.B.; Jankowski, P. Spatial decision support systems: Three decades on. Decis. Support Syst. 2019, 116, 64–76. [Google Scholar] [CrossRef]
- Mondejar, M.E.; Avtar, R.; Diaz, H.L.B.; Dubey, R.K.; Esteban, J.; Gómez-Morales, A.; Hallam, B.; Mbungu, N.T.; Okolo, C.C.; Prasad, K.A.; et al. Digitalization to achieve sustainable development goals: Steps towards a Smart Green Planet. Sci. Total Environ. 2021, 794, 148539. [Google Scholar] [CrossRef]
- Shan, S.; Yan, Q. Emergency Response Decision Support System, 1st ed.; Springer: Singapore, 2017; Volume XII, p. 70. [Google Scholar] [CrossRef]
- Jana, S.; Majumder, R.; Menon, P.P.; Ghose, D. Decision Support System (DSS) for Hierarchical Allocation of Resources and Tasks for Disaster Management. Oper. Res. Forum 2002, 3, 37. [Google Scholar] [CrossRef]
- Bazilevych, K.O.; Chumachenko, D.I.; Hulianytskyi, L.F.; Meniailov, I.S.; Yakovlev, S.V. Intelligent Decision-Support System for Epidemiological Diagnostics. I. A Concept of Architecture Design. Cybern. Syst. Anal. 2022, 58, 343–353. [Google Scholar] [CrossRef]
- Ditta, A.; Figueroa, O.; Galindo, G.; Yie-Pinedo, R. A Review on Research in Transportation of Hazardous Materials. Socio-Econ. Plan. Sci. 2019, 68, 100665. [Google Scholar] [CrossRef]
- Nasar, W.; Da Silva Torres, R.; Gundersen, O.E.; Karlsen, A.T. The Use of Decision Support in Search and Rescue: A Systematic Literature Review. ISPRS Int. J. Geo-Inf. 2023, 12, 182. [Google Scholar] [CrossRef]
- Lubkowski, P.; Krygier, J.; Sondej, T.; Dobrowolski, A.P.; Apiecionek, L.; Znaniecki, W.; Oskwarek, P. Decision Support System Proposal for Medical Evacuations in Military Operations. Sensors 2023, 23, 5144. [Google Scholar] [CrossRef]
- Zhai, Z.; Martínez, J.F.; Beltran, V.; Martínez, N.L. Decision Support Systems for Agriculture 4.0: Survey and Challenges. Comput. Electron. Agric. 2020, 170, 105256. [Google Scholar] [CrossRef]
- Fertier, A.; Barthe-Delanoë, A.M.; Montarnal, A.; Truptil, S.; Bénaben, F. A New Emergency Decision Support System: The Automatic Interpretation and Contextualisation of Events to Model a Crisis Situation in Real-Time. Decis. Support Syst. 2020, 133, 113260. [Google Scholar] [CrossRef]
- Jones, E.K.; Hultman, G.; Schmoke, K.; Ninkovic, I.; Dodge, S.; Bahr, M.; Melton, G.B.; Marquard, J.; Tignanelli, C.J. Combined Expert and User-Driven Usability Assessment of Trauma Decision Support Systems Improves User-Centered Design. Surgery 2022, 172, 1537–1548. [Google Scholar] [CrossRef] [PubMed]
- Hassanien, A.E.; Azar, A.T.; Snasael, V.; Kacprzyk, J.; Abawajy, J.H. Big Data in Complex Systems in Studies in Big Data; Springer International Publishing: Cham, Switzerland, 2015. [Google Scholar] [CrossRef]
- Abbasi, A.; Sarker, S.; Chiang, R.H.L. Big data research in information systems: Toward an inclusive research agenda. J. Assoc. Inf. Syst. 2016, 17, 3. [Google Scholar] [CrossRef]
- Kukar, M.; Vračar, P.; Košir, D.; Pevec, D.; Bosnić, Z. AgroDSS: A Decision Support System for Agriculture and Farming. Comput. Electron. Agric. 2019, 161, 260–271. [Google Scholar] [CrossRef]
- Sadeghi, M.; Carenini, A.; Corcho, O.; Rossi, M.; Santoro, R.; Vogelsang, A. Interoperability of heterogeneous Systems of Systems: From requirements to a reference architecture. J. Supercomput. 2023, 1–34. [Google Scholar] [CrossRef]
- Samuelsen, J.; Chen, W.; Wasson, B. Integrating multiple data sources for learning analytics—Review of literature. Res. Pract. Technol. Enhanc. Learn. 2019, 14, 11. [Google Scholar] [CrossRef]
- Bashatah, J.A.; Sherry, L. A model-based approach for the qualification of standard operating procedures. In Proceedings of the Integrated Communications Navigation and Surveillance Conference (ICNS), Dulles, VA, USA, 19–23 April 2021; pp. 1–10. [Google Scholar] [CrossRef]
- Tsavdaridis, G.; Koukoutsis, E.; Karadimas, N.V. Panspermia of GeoData in Support Systems for Design and Execution of Operational Procedures. In Proceedings of the 3rd International Conference on Mathematics and Computers in Sciences and Industry (MCSI) Chania, Crete Island, Greece, 27–29 August 2016; pp. 202–207. [Google Scholar] [CrossRef]
- Tsavdaridis, G.; Koukoutsis, E.; Karadimas, N.V. Techniques Handling Operational Information during Military Decision-Making Process. In Proceedings of the 3rd European Conference on Electrical Engineering & Computer Science (EECS), Athens, Greece, 28–30 December 2019; pp. 117–122. [Google Scholar] [CrossRef]
- Koukoutsis, E.; Papaodysseus, C.; Tsavdaridis, G.; Karadimas, N.V.; Ballis, A.; Mamatsi, E.; Mamatsis, A.R. Design Limitations, Errors and Hazards in Creating Decision Support Platforms with Large- and Very Large-Scale Data and Program Cores. Algorithms 2020, 13, 341. [Google Scholar] [CrossRef]
- Fotopoulos, E. Towards a Particularly Controllable, Robust, and Thematically Strong Information Model in the Field of Transportation. Master’s Thesis, National Technical University of Athens, Athens, Greece, 2018. [Google Scholar] [CrossRef]
- Tsavdaridis, G. Needs for Specially Handling Georeferenced Information in Crises Management Systems and Systems for Monitoring and Control of Operational Procedures. Master’s Thesis, National Technical University of Athens, Athens, Greece, 2013. [Google Scholar] [CrossRef]
- Lee, E.B.K.; Van Bossuyt, D.L.; Bickford, J.F. Digital Twin-Enabled Decision Support in Mission Engineering and Route Planning. Systems 2021, 9, 82. [Google Scholar] [CrossRef]
- Wielgosz, M.; Malyszko, M. Multi-Criteria Selection of Surface Units for SAR Operations at Sea Supported by AIS Data. Remote Sens. 2021, 13, 3151. [Google Scholar] [CrossRef]
- Lemons, G.T.; Carrington, K. F-35 Mission Systems Design, Development and Verification. In Proceedings of the Aviation Technology, Integration, and Operations Conference, Atlanta, GA, USA, 25–29 June 2018. [Google Scholar] [CrossRef]
- Paula, N.; Areias, B.; Reis, A.B.; Sargento, S. Multi-drone Control with Autonomous Mission Support. In Proceedings of the IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), Kyoto, Japan, 11–15 March 2019. [Google Scholar] [CrossRef]
- Lassoued, H.; Ketata, R.; Yacoub, S. ECG Decision Support System based on feedforward Neural Networks. Int. J. Smart Sens. Intell. Syst. 2018, 11, 1–15. [Google Scholar] [CrossRef]
- Kochilakis, G.; Poursanidis, D.; Chrysoulakis, N.; Varella, V.; Kotroni, V.; Eftychidis, G.; Lagouvardos, K.; Papathanasiou, C.; Karavokyros, G.; Aivazoglou, M.; et al. A web based DSS for the management of floods and wildfires (FLIRE) in urban and periurban areas. Environ. Model. Softw. 2016, 86, 111–115. [Google Scholar] [CrossRef]
- Camacho-Collados, M.; Liberatore, F. A Decision Support System for predictive police patrolling. Decis. Support Syst. 2015, 75, 25–37. [Google Scholar] [CrossRef]
- Konoplin, A.; Konoplin, N.; Yurmanov, A. Development and Field Testing of a Smart Support System for ROV Operators. J. Mar. Sci. Eng. 2022, 10, 1439. [Google Scholar] [CrossRef]
- Stamatescu, I.; Arghira, N.; Făgărăşan, I.; Stamatescu, G.; Iliescu, S.; Calofir, V. Decision Support System for a Low Voltage Renewable Energy System. Energies 2017, 10, 118. [Google Scholar] [CrossRef]
- Filip, F.G. DSS—A Class of Evolving Information Systems. In Data Science: New Issues, Challenges and Applications. Studies in Computational Intelligence; Dzemyda, G., Bernatavičienė, J., Kacprzyk, J., Eds.; Springer: Cham, Switzerland, 2020; p. 869. [Google Scholar] [CrossRef]
- Privalov, A.A.; Kolesov, V.A.; Veremiev, V.I. Decision Support System for Integrated Geo-Information Environmental Monitoring. In Proceedings of the XXVI International Conference on Soft Computing and Measurements (SCM), Saint Petersburg, Russia, 24–26 May 2023; IEEE: Piscataway, NJ, USA, 2023. [Google Scholar] [CrossRef]
- Aspen, D.M.; Hellevik, C.C. Building Decision Support Systems for Sustainable Transitions. In Business Transitions: A Path to Sustainability; Fet, A.M., Ed.; Springer: Cham, Switzerland, 2023. [Google Scholar] [CrossRef]
- Sligo, J.; Gauld, R.; Roberts, V.; Villa, L. A literature review for large-scale health information system project planning, implementation, and evaluation. Int. J. Med. Inform. 2017, 97, 86–97. [Google Scholar] [CrossRef]
- Eom, S.B. Evolution of DSS from Single User DSS to Inter-Organizational DSS. In Inter-Organizational Information Systems in the Internet Age; IGI Global: Hershey, PA, USA, 2005; pp. 231–247. [Google Scholar] [CrossRef]
- Bohanec, M. From Data and Models to Decision Support Systems: Lessons and Advice for the Future. In EURO Working Group on DSS. Integrated Series in Information Systems; Papathanasiou, J., Zaraté, P., Freire de Sousa, J., Eds.; Springer: Cham, Switzerland, 2021. [Google Scholar] [CrossRef]
- Carbone, A.; Jensen, M.; Sato, A. Challenges in Data Science: A Complex Systems Perspective. Chaos Solitons Fractals 2016, 90, 1–7. [Google Scholar] [CrossRef]
- Winroth, M.; Safsten, K.; Stahre, J. Automation Strategies: Existing Theory or Ad Hoc Decisions? Int. J. Manuf. Technol. Manag. 2007, 11, 98. [Google Scholar] [CrossRef]
- Bui, T.X. Decision Support systems for Sustainable Development. In Decision Support Systems for Sustainable Development; Kersten, G.E., Mikolajuk, Z., Yeh, A.G.O., Eds.; Springer: Boston, MA, USA, 2002. [Google Scholar] [CrossRef]
- Dwivedi, Y.K.; Wastell, D.; Laumer, S.; Henriksen, H.Z.; Myers, M.D.; Bunker, D.; Amany Elbanna, M.N.; Srivastava, R.S.C. Research on information systems failures and successes: Status update and future directions. Inf. Syst. Front. 2015, 17, 143–157. [Google Scholar] [CrossRef]
- Jacko, J.A. Fundamentals, Evolving Technologies, and Emerging Applications. In The Human–Computer Interaction Handbook, 3rd ed.; CRC Press: Boca Raton, FL, USA, 2012. [Google Scholar] [CrossRef]
- Benson, T.; Grahame, G. Why Interoperability Is Hard. In Health Information Technology Standards; Springer: Berlin/Heidelberg, Germany, 2020; pp. 21–40. [Google Scholar] [CrossRef]
- Kushwaha, A.K.; Kar, A.K.; Dwivedi, Y.K. Applications of Big Data in Emerging Management Disciplines: A Literature Review Using Text Mining. Int. J. Inf. Manag. Data Insights 2021, 1, 100017. [Google Scholar] [CrossRef]
- Drieschner, M.; Petryna, Y.; Freitag, S.; Edler, P.; Schmidt, A.; Lahmer, T. Decision Making and Design in Structural Engineering Problems under Polymorphic Uncertainty. Eng. Struct. 2021, 231, 111649. [Google Scholar] [CrossRef]
- Patrick, D.H. The Information Security Organization. In FISMA Principles and Best Practices; CRC Press: Boca Raton, FL, USA, 2016; pp. 77–96. [Google Scholar] [CrossRef]
- Drieschner, M.; Petryna, Y.; Freitag, S.; Edler, P.; Schmidt, A.; Lahmer, T. Simplifying Reward Design through Divide-and-Conquer. arXiv 2018, arXiv:1806.02501. [Google Scholar] [CrossRef]
- Ballis, A. Implementing the European Transport Information System. Transp. Res. Rec. J. Transp. Res. Board 2006, 1957, 23–31. [Google Scholar] [CrossRef]
- Kavvadia, H. Teleology in Systems Analysis and Design Methods. SSRN Electron. J. 2020, 1–24. [Google Scholar] [CrossRef]
- Hariri, R.H.; Fredericks, E.M.; Bowers, K.M. Uncertainty in big data analytics: Survey, opportunities, and challenges. J. Big Data 2019, 6, 44. [Google Scholar] [CrossRef]
- Hemmings, B.; Knowling, M.J.; Moore, C.R. Early uncertainty quantification for an improved decision support modeling workflow: A streamflow reliability and water quality example. Front. Earth Sci. 2020, 8, 565613. [Google Scholar] [CrossRef]
- Marashi-Hosseini, L.; Jafarirad, S.; Hadianfard, A.M. A fuzzy based dietary clinical decision support system for patients with multiple chronic conditions (MCCs). Sci. Rep. 2023, 13, 12166. [Google Scholar] [CrossRef]
Num | Advantages/Benefits | Potential Limitations |
---|---|---|
1 | Systematically and specifically preprocess input data before feeding them into the system, thereby easing the workload for operational experts. | The system cannot assess in its current form the validity of input data, which may lead to the Garbage In, Garbage Out (GIGO) phenomenon. |
2 | Additional organization of the system’s input data into smaller and focused sub-sets tailored to the specific data requirements of actionable actors, thus preventing systems’ information overload. | It is required to conduct comprehensive interviews with operational specialists from diverse fields to assess the data and program requirements that would support the operational processes they manage. These interviews are instrumental in gathering a wide variety of critical operational information. |
3 | Development of a diagrammatic algorithm specifically for transportation mission planning using the GraphML format. This method not only enables code generation but also supports back annotation, meaning changes in code are reflected back directly within the diagram. | There is no automation in the interface with a user, like the existence of an LLM-powered chatbot. |
4 | Design the mission using the “divide and conquer” principle, effectively breaking down complex tasks into smaller, more manageable segments. | The extent of thematic breakdown in a complex mission is always contingent on the operational expertise and qualifications of the experts involved in mission planning. |
Num | Advantages/Benefits | Potential Limitations |
---|---|---|
1 | The use of AIS data equips the system with a dependable foundation for making decisions, thereby guaranteeing the choice of the most appropriate vessels based on data-driven insights. | The system’s efficiency hinges on the precision and comprehensiveness of AIS data, which might not always be dependable or accessible, raising concerns about data reliability and coverage. |
2 | The multi-criteria analysis method enables the consideration of diverse criteria, ensuring a thorough evaluation of each vessel’s appropriateness. | Implementing the multi-criteria decision-making process can be intricate, often necessitating substantial expertise and resources for effective execution. |
3 | The system facilitates the effective choice of surface units for Search and Rescue (SAR) operations in high-traffic-density areas, thereby improving the speed and efficiency of these operations. | The system’s effectiveness in real-time decision making can be impacted by the dynamic marine environment, including rapidly changing sea conditions such as weather and sea states. |
Num | Advantages/Benefits | Potential Limitations |
---|---|---|
1 | A modular and comprehensive control system for drones, designed for easy operation by inexperienced users. | Complexity in system scaling and integration into diverse scenarios. |
2 | The system also offers increased mission flexibility, as a set of drones can dynamically adapt to different missions, such as increasing area coverage capacity | Dependence on particular communication protocols and specific hardware configurations. |
3 | Long communication range with real-time control, enhancing mission flexibility. | Constraints in direct drone-to-drone communication in the absence of ground support. |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2024 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Tsavdaridis, G.; Papaodysseus, C.; Karadimas, N.V.; Papazafeiropoulos, G.; Delis, A. Methodologies and Handling Techniques of Large-Scale Information in Decision Support Systems for Complex Missions. Appl. Sci. 2024, 14, 1995. https://doi.org/10.3390/app14051995
Tsavdaridis G, Papaodysseus C, Karadimas NV, Papazafeiropoulos G, Delis A. Methodologies and Handling Techniques of Large-Scale Information in Decision Support Systems for Complex Missions. Applied Sciences. 2024; 14(5):1995. https://doi.org/10.3390/app14051995
Chicago/Turabian StyleTsavdaridis, George, Constantin Papaodysseus, Nikolaos V. Karadimas, George Papazafeiropoulos, and Athanasios Delis. 2024. "Methodologies and Handling Techniques of Large-Scale Information in Decision Support Systems for Complex Missions" Applied Sciences 14, no. 5: 1995. https://doi.org/10.3390/app14051995
APA StyleTsavdaridis, G., Papaodysseus, C., Karadimas, N. V., Papazafeiropoulos, G., & Delis, A. (2024). Methodologies and Handling Techniques of Large-Scale Information in Decision Support Systems for Complex Missions. Applied Sciences, 14(5), 1995. https://doi.org/10.3390/app14051995