Update paper.md

Author: pradeeban

paper.md

@@ -59,22 +59,27 @@ bibliography: paper.bib
 
 ---
 # Summary
-Closed-loop Vagus Nerve Stimulation (VNS) based on physiological feedback signals is a promising approach to regulating organ functions and developing therapeutic devices. Designing closed-loop neurostimulation systems requires simulation environments and computing infrastructures that support i) modeling the physiological responses of organs under neuromodulation, also known as physiological models (PMs), and ii) the interaction between the PMs and the neuromodulation control algorithms. However, existing simulation platforms do not support closed-loop VNS control systems modeling without extensive rewriting of computer code and manual deployment and configuration of programs.
 
-The CONTROL-CORE framework aims to develop a flexible software platform for designing and implementing closed-loop VNS systems. The CONTROL-CORE framework consists of the _concore_ protocol at its core. The _concore_ protocol allows seamless synchronized communication between the programs (such as PMs and controllers) that compose a study as a workflow. _concore_ allows simulations to run on different operating systems, be developed in various programming languages (such as Matlab, Python, C++, and Verilog), and be run locally, in containers, and in a distributed fashion. CONTROL-CORE also consists of a Mediator implementation that facilitates the distributed execution of _concore_ studies through REST calls over the Internet.
+The CONTROL-CORE framework is a flexible software platform for designing and implementing closed-loop Vagus Nerve Stimulation (VNS) systems in programming languages in diverse software environments. Its modular workflow approach for closed-loop executions of the VNS simulations aims to facilitate modeling organ functions as physiological models (PMs) and therapeutic devices in their early stages in a software environment. 
 
+The CONTROL-CORE framework consists of the _concore_ protocol at its core. The _concore_ protocol allows seamless synchronized communication between the programs (such as PMs and controllers) that compose a study as a workflow. _concore_ enables simulations to run on different operating systems, be developed in various programming languages (such as Matlab, Python, C++, and Verilog), and be run locally, in containers, and a distributed fashion. 
 
-CONTROL-CORE contains a lightweight browser-based visual _concore_ editor, which lets the users create studies from the programs in a drag-and-drop manner. It allows creation of directed hypergraphs to represent the studies with closed-loop from modular programs and exporting the directed hypergraph workflows as GraphML files. _concore_ consists of a parser that parses and interprets the studies represented in the GraphML file and execute the studies seamlessly as modular workflows until a specified maxtime value for the study (exit condition, to ensure the closed-loop workflow does not execute forever) is met.
+CONTROL-CORE also consists of a Mediator implementation that facilitates the distributed execution of _concore_ studies through REST calls over the Internet. When the Mediator is deployed to enable inter-organization workflows with services spread across the Internet, access control and authentication mechanisms must be used to protect the shared data. The Mediator leverages the API key-based authentication provided by the Kong API gateway to enable such Internet deployment.
 
+CONTROL-CORE contains a lightweight browser-based visual _concore_ editor, which lets the users create studies from the programs in a drag-and-drop manner. It allows the creation of directed hypergraphs to represent the studies with closed-loop from modular programs and exporting the directed hypergraph workflows as GraphML files. _concore_ consists of a parser that parses and interprets the studies represented in the GraphML file and executes the studies seamlessly as modular workflows until a specified maximum time value for the study is met. This exit condition ensures the closed-loop workflow does not run forever, as closed-loop studies do not contain a predefined end step, unlike the classic workflows with an end step.
 
-We tested _concore_ in the context of closed-loop control of cardiac physiological models, including pulsatile and nonpulsatile rat models. These were tested using various controllers such as Model Predictive Control and Long-Short-Term Memory-based controllers. Our wide range of use cases and evaluations show the performance, flexibility, and usability of _concore_. The scientific contributions of _concore_ protocol and the CONTROL-CORE framework, along with these sample closed-loop neuromodulation control systems studies have been extensively discussed in our previous work [@kathiravelu2022control].
+# Statement of need
 
+Existing software ecosystems are not tailored for the modeling and simulation of closed-loop control systems developed in multiple programming languages. Containerization with frameworks such as Docker has become popular across the scientific community as containerization enables reproducible science with minimal effort. Workflow frameworks can execute a series of containerized programs without human-in-the-loop, with services/programs as predefined start and end steps. Workflows facilitate modular development as they enable the execution of a series of programs without manually managing each program individually. Typically, these programs are developed and shared across the users as containerized services. Such workflows do not have a cycle, by definition.
 
-# Statement of need
+On the other hand, a neuromodulation control system comprises feedback loops represented by directed cycles (dicycles). The presence of a dicycle violates the core tenet of classic workflow frameworks, such as Common Workflow Language (CWL) and Workflow Description Language (WDL), which expect the studies to be represented by a directed acyclic graph (DAG). Furthermore, control systems run the same program multiple times as part of the execution with feedback. Consequently, overheads imposed by workflow frameworks, significantly when handling implementations across diverse programming languages and execution environments, are magnified in the case of a closed-loop execution.
+
+Interoperability plays a significant role in scientific research. Therefore, we should support the modeling and simulation of studies composed of programs developed in different programming languages, executing on different execution modes (local, distributed, or containerized). _concore_ is designed for efficiency in control systems' specific use cases, supporting interoperable communication and data exchange between programs from independent researchers. The simple file-based communication and synchronization of _concore_, without a centralized workflow orchestrator, enables interoperable executions with high performance.
+
+# Research works enabled by _concore_
 
-Existing software ecosystems are not tailored for the modeling and simulation of closed-loop control systems developed in multiple programming languages. Containerization with frameworks such as Docker has become popular across the scientific community as containerization enables reproducible science with minimal effort. Workflow frameworks can execute a series of containerized programs without human-in-the-loop, with services/programs as predefined start and end step. Workflows facilitate a modular development as they enable execution of a series of a programs without manually managing the each program individually. Typically, these programs are developed and shared across the users containerized services. Such workflows do not have a cycle, by definition. On the other hand, a neuromodulation control system comprises feedback loops represented by directed cycles (dicycles). The presence of a dicycle violates the core tenet of classic workflow frameworks, such as Common Workflow Language (CWL) and Workflow Description Language (WDL), which expect the studies to be represented by a directed acyclic graph (DAG). Furthermore, control systems run the same program multiple times as part of the execution with feedback. Consequently, overheads imposed by workflow frameworks, significantly when handling implementations across diverse programming languages and execution environments, are magnified in the case of a closed-loop execution.
+The _concore_ protocol has been used to simulate closed-loop control of cardiac physiological models, with various controllers such as Model Predictive Control and Long-Short-Term Memory-based controllers. The scientific contributions of _concore_ protocol and the CONTROL-CORE framework, along with these sample closed-loop neuromodulation control systems use cases, have been extensively discussed in our previous work [@kathiravelu2022control].
 
-Interoperability plays a significant role in scientific research. Therefore, we should support the modeling and simulation of studies composed of programs (such as the controllers and PMs) developed in different programming languages, executing on different execution modes (local, distributed, or containerized). _concore_ is designed for efficiency in control systems' specific use cases, supporting interoperable communication and data exchange between programs from independent researchers. The simple file-based communication and synchronization, without a centralized workflow orchestrator, enables interoperable executions with high performance.
 
 # Acknowledgment