dataesr/scientific-paragraphs-categorization huggingface dataset:
The OceanSITES data policy and the OceanSITES NetCDF data file format and file dissemination are important achievements. However, even for the data dissemination, some of the biological and biogeochemical data that need complex, comprehensive documentation on methods and agreement from a global community have not converged (e. g. , sediment trap data). Searching the OBPS repository for Eulerian observatories related keywords 24  Eulerian (19), OceanSITES (27), FIXO3 (7), Mooring (151), PIRATA (11), RAMA (9), TPOS (3), TOGA-TAO (5), EMSO (5), EuroSites (2), and OOI (7) revealed the existing documentation (number of documents given in brackets). This is a major achievement of the repository as a similar search would not be possible with other search engines. Another benefit of the OBPS is that best practices can be paired with other documentation that deal with generic techniques (e.
g. , conversion of acoustic backscatter intensity into target strength) relevant to Eulerian observatories in order to produce a broad harmonization of applicable practices. In order to best leverage the investments in Eulerian observatories, regional and global coordination is mandatory. The integration is closely linked to appropriate best practices and their documentation regarding sensor handling, analysis techniques, or data reduction. This includes for example, data from sediment traps (carbon export), air-sea fluxes measured by the surface buoys, or all types of quality control data. With increasing maturity of sensors (e. g. , pH, pCO2, zooplankton imagery) and emerging techniques (e. g. , 'omics'), new best practices will need to be created. Documentation of these practices in the repository will support enhanced harmonization across the Eulerian observatories networks on a regional to global scale.
Assessing the Performance of Ocean Monitoring Systems There is a need to optimize the investments in ocean observing and to understand how marine monitoring data and information can be effective and reliable for developing societally relevant products. The first community-based best practice for monitoring systems that incorporates end-user products has been developed by the European Marine Observation and Data Network 29. The practice, called a "Sea-Basin Checkpoint" 30  , produces an assessment of monitoring systems at the scale of the European Seas. An essential component of the Sea-Basin Checkpoint framework is the definition of assessment criteria and their measurable indicators. A unique Checkpoint assessment best practice was developed for three European sea basins (North Atlantic, Mediterranean Sea, and Black Sea).
The results for these basins demonstrated that the Checkpoint assessment is feasible and has led to a promising methodology (best practice). During the development, several challenges were encountered in creating the best practice. One was the establishment of a proper end-user product specifications and the evaluation of the monitoring adequacy on the basis of comprehensive indicators  (Pinardi et al. , 2017). Another challenge was to have a sufficient number of end-user products to estimate the data and information adequacy across application sectors. In the short term, the Sea-Basin Checkpoint assessment framework has to gain acceptance by a larger community. The methods for the Mediterranean Checkpoint have been documented in the OBPS repository  (Manzella et al. , 2017)  to encourage review and dialogue of these methods.
This is due to a lack of agreed upon methods across different observing programs. Harmonizing QA/QC procedures for the collected data across different observational programs is essential. The best practice creation process at a component or system level starts with documenting all integration, design details and routine maintenance procedures. It is also critical to document real-time data QA/QC. In formulating quality control best practices, the breadth of the challenge requires many detailed manuals, each focused on a different facet of quality control 32. Over the last decade, many such manuals were created and peer reviewed. These are all available in the OBPS repository. The implementation of this quality assurance strategy on a global level will need the support and concurrence of international organizations such as GOOS, IODE, and JCOMM.
Repository Benefiting from the developments in Section "OBPS Evolution, " the repository will expand its range of services and provide interfaces with resources in other infrastructures in the coming years. The descriptions of best practices through its associated metadata will be expanded and standardized to further improve search and access. Further, existing templates will be updated to render their contents more machine actionable. The repository will also develop approaches to link methods to any data, software or code they reference. For example, persistent Uniform Resource Locators (URLs) 35  linking methods to reference data sets hosted in trusted archives will become a common feature among best practices. Further, dated links to version controlled Github repositories 36 and/or Jupyter notebooks 37 will provide software and process connectivity as well as reproducibility of software executable processes.
Peer Review A process to identify preferred practices for defined applications and/or scenarios is a necessary part of the OBPS evolution. Currently, GOOS together with OBPS are developing a process to identify methods suitable to measure and report on the EOVs. To complement this review model, OBPS is exploring crowd-sourcing approaches to assess community support and adoption for methods in the system. Social media functionality including up-or down-voting coupled with commenting has had remarkable success in web platforms such as StackOverflow 38. Indeed, several academic journals have incorporated forms of 36 https://github. com 37 https://jupyter. org 38 https://stackoverflow. com community review and hybrid models  (Walker and Rocha da Silva, 2015). OBPS is exploring such hybrid systems to maximize community involvement, including through the Frontiers in Marine Science Research Topic on Best Practices in Ocean Observing.
ACKNOWLEDGMENTS We acknowledge the contributions of some of the authors (MB, PB, CCh, FM-K, JH, EH, JK, CM-M, FP, JP, PP, NR, and PS) to the Ocean Best Practice Working Group that has been instrumental in building the foundation for the Ocean Best Practice System. We would like to thank  LL  and  ML  for their thoughtful contributions as reviewers, which resulted in many improvements in the manuscript. We would like to thank  Nina Hall  and  Brittany Alexander  for their support in creating and maturing the  Frontiers in Marine Science Best Practices in Ocean Observing Research Topic.
Selection of articles This review intends to collect papers in which ABM and LCA have been coupled. A focus is carried out on all papers presenting a case study or a proof of concept in order to be able to analyse how the coupling was carried out from a methodological point of view. Since this concern is relatively new, no temporal restriction has been applied. The exhaustive search was performed with international bibliographic databases, Scopus, ISI Web Science, Science Direct and Google Scholar, with a combination of keywords relating to "Agent-based model*" (or "ABM" or "Multi-agent system" or "MAS") AND "Life cycle assessment" (or "LCA" or "Life cycle analysis"). Articles using the LCA acronym with another meaning (for example, local control agent or local configuration approximation) were excluded.
Soft-coupling: ABM outputs obtained at the end of the simulation are aggregated and are used as inputs for LCA analysis. Tight-coupling: ABM outputs are used as inputs of the LCA at each time step. Hard-coupling: Data are exchanged between LCA and ABM at each time step (LCA results are used as an input parameter for the ABM simulation). Affected parts of the LCA computational structure. Within the context of LCA, ABM can be used to simulate different types of systems: production system, consumption system or environmental system. As introduced in the introduction, the production system refers to the assembly of activities that are required to transform inputs into deliverable outputs (goods or services), from the supply chain to the market. Once removed from the market, the consumption of finished products and services can be described by the frequency, the quantities of products that are consumed and the way the product is used.
Cognitive and technological agents can (i) interact among them, (ii) interact with other types of agents and (iii) interact with the static supply chain, if one has been previously defined by databases. These interactions are an essential driver of the decision-making process. In Wu et al. 's agent-based model, green building coverage is driven by the interactions between the government, the inhabitants and the developers. Developers are encouraged by the incentives set each year by the government and by public perception to move towards green building construction. Households' environmental awareness evolves at each time step as a function of their neighbours. One of the key specificities of ABMs is the high number of agents that can be simulated. Vasconcelos et al. (2017)  simulate as many travellers as inhabitants in Lisbon, which are 547733.
Type of coupling. Regarding the type of coupling: -Four papers do not mention the type of coupling they use. -Complementary use has been experimented in two studies. ABM and LCA were used separately by  Pambudi et al. (2016)  and  Onat et al. (2017). In these cases, ABM was used to determine the rate of adoption of several potential waste management systems (respectively electric car) since the community (respectively consumers) involvement and acceptation are necessary to assess sustainable plastic waste management (respectively battery electric vehicles), while LCA was used to assess the environmental impact of the different strategies. LCA results are not scaled according to this adoption rate. -LCA and ABM are integrated in seven studies. Davis, Nikolíc and Gerard P. J. Dijkema (2009)  were the first to extend LCA with ABM: in their model, the static LCA database can be considered as a WorldMarket agent with which the other Technological agents can interact.
The same procedure was used by  Walzberg et al. (2018). The authors represented some of the system processes from the LCA database ecoinvent 3. 1, such as Appliances agents evolving at each time step according to their Switch On/Off position. The five other articles  (Xu et al. , 2009; Miller et al. , 2013; Bichraoui-Draper et al. , 2015; Lu and Hsu, 2017; Vasconcelos et al. , 2017)  run an LCA calculation directly into their agent-based model and they do not use specific LCA software. -A hybrid analysis has been used in 28% of the articles. For all these articles, the consumption system is modelled by ABM and the affected part of the LCA computational structure is the final demand vector. Attallah et al. (2014) use LCA to quantify the avoided impact at the project level (residential building) according to the selected credits of the certification that is targeted.
Degree of coupling. Regarding the degree of coupling, hard-coupling is used 22% of the time, against 67% for the soft-coupling as described Table  4. Tight-coupling has never been used, and the 11% remaining articles do not have any degree of coupling, since ABM and LCA are used in a complementary way. Walzberg, Samson and Merveille (2018) used a hard-coupling to manage temporally disaggregated data of the electricity mix. At each hour of the day, they consider the impact associated with the on-or off-peak electricity mix, so their model requires a flow of data at each time step (running LCA calculation needs as inputs the dynamic state of the agent Appliance). Affected parts of the LCA computational structure. In the corpus under study, the technosphere matrix and the final demand vector were the affected computational parts.
Inventory LCA foreground/background data. For most studies, inventories of the foreground LCA data were collected from ABM simulations. The ABM results were used to create the final demand vector. Elementary flows associated to the foreground data are obtained from existing LCA studies from literature in many studies  (Xu et al. , 2009; Lu and Hsu, 2017; Onat et al. , 2017; Vasconcelos et al. , 2017). Vasconcelos et al. 2017  used an existing life cycle assessment to compute the quantity of air pollutant and greenhouse gases emissions for each kilometre travelled by car (functional unit). A total of 31% of the studies used the Ecoinvent life cycle inventory database  (Weidema et al. , 2013)  as background data, either imported in the ABM for integrated models  (Davis, Nikolíc and Dijkema, 2009; Walzberg et al.
, 2018) , which were run thanks to an LCA dedicated software for hybrid coupling or ABM inputs. ABMs can be complex and often require a considerable amount of socio-demographic or -economic data to set up the design of the agent's profile. Four studies  (Navarrete Gutierrez et al. 2015; Lu & Hsu 2017; Hicks et al. 2015; Attallah 2014 ) are based on surveys that were previously elaborated by the research team. For example, Omar  Attallah et al. (2014)  designed and analysed statically survey questions to identify the different stakeholders and determine their attributes. In addition to data at the agent level, ABM also uses contextual data specific to the environment. For example,  (Walzberg et al. , 2018)  used the national weather database to determine heating needs. Three studies  (Heairet et al.
, 2012; Lu and Hsu, 2017; Bustos-Turu et al. 2016 ) used spatialized information from geographic information system (GIS), a tool that represents and analyses spatial information. Three others  (Bichraoui-Draper et al. , 2015; Miller et al. , 2013; Navarrete Gutierrez et al. ,2015)  evoke the possibility of adding GIS extension to directly model the map and to extract environmental parameters. In integrated models, every LCA calculations are computed directly in the ABM thanks to the importation of the necessary databases or parameters values. For studies with a hybrid approach, no information about the interconnection between both models is given, apart from  (Navarrete Gutierrez et al. , 2015a)  who use SysML for data-management. If an LCA software is used (e. g. , Gabi and Simapro), a protocol must be created.
Methodological issues: how can the coupling be done? The way that both tools are coupled depends on the expected consistency and flexibility. Integrating LCA with ABM leads to a consistent, unique model, but models are highly dependent, since the ABM architecture is embedded in the LCA data structure. The main drawback lies in the difficulty in developing an integrated model, since the modeler must have expertise in both computer science and environmental engineering fields. However, integration is highly recommended when ABM is embedded in LCA, i. e. , when ABM does not represent the whole system but models a process (already existing or not in LCA) that interacts with other LCA processes within this system. Thus, ABM and LCA integration is relevant when the dynamic effects in a matrix system of the LCA computational structure is partly modelled by ABM, i.
Thus, decision-makers can be involved from the early modelling stages and, as underlined by  (Marvuglia et al. , 2018) , the transparency of these participatory modelling processes favour the acceptance of the final decision by different stakeholders. Besides, these platforms are continuously upgraded, and one could imagine that they could later automatically integrate the LCA data, as some already do with GIS for example (e. g. , GAMA). The use of GIS data, as well as national databases as inputs to the agent-based model, generates highly contextspecific LCA studies. This enables to account for the specificities of different countries and further identify targeted policies; however, this also prevents the results from extrapolating to other situations or from using the model in another context.
Davis, Nikolíc and Dijkema (2009)  were the first to highlight that the use of LCA databases can ease the creation of a complex technological environment in ABM. An interesting research approach would be to transform every unit process from an existing LCA database into agents and to assign them interactions with each other according to the flows that are quantified in the database. The environmental impact that is associated with the response of the production system to the consumption demand could be assessed this way.
In particular ISO/IEC/IEEE 15288 "Systems and software engineering System life cycle processes" defines four groups of processes: agreement processes, organisational project-enabling processes, project processes and technical processes. In fact technical processes also highlight the need to define user requirements including safety considerations during the requirement analysis process. Other guides such as  [50]  do not intend to ensure safety nor security aspects. These kinds of standards and guidelines do not prescribe any specific approach to tackle safety, security and performance considerations at the same time in a coherent PLC approach. In AQUAS we propose a particular type of mechanism -interaction points -which is orthogonal to any model of life-cycle and can occur at different stages of the life-cycle and allow for combined analysis to be applied and take into account simultaneously the concerns relevant for the particular development context.
Thus a challenge for AQUAS is how to ensure effective, efficient combined analyses at these interaction points that occur during operation. One of the questions is where, in the timeline of the PLC, interaction points should be placed. Combined analyses could be continuously repeated every time that any of the development artefacts changes, giving a guarantee of spotting early any risk of violating requirements and any opportunity for optimization; but this will not be cost-effective; if on the other hand much design refinement or change takes place without cross-checks, the costs of backtracking if problems are found, or the opportunity cost of missed optimization chances, may be large. The concern is analogous to what is sometimes called "technical debt"  [51]  : if rapid software implementation is pursued without the software engineering investment that makes for longer-term cost-effectiveness, extra costs will be incurred in maintenance, late refactoring, operational failures.
This integration can be done by modelling Safety Cases (e. g. , using GSN (Goal Structuring Notation)/CAE (Claim -Argument -Evidence) tools) including facilities to define and trace these concepts (safety, security and performance). For doing this we can use the Opencoss platform  [52]  released under Eclipse/Polarsys initiative. AQUAS aims at incorporating safety, security and performance concepts in a common approach in order to reconcile and harmonise them within a product life cycle in a safety critical domain. In this sense AQUAS investigates the relationships among these concepts (safety, security and performance) and their relationships among standards such as ISO 26262, IEC 61508, or DO-178C. In addition AQUAS provides a product life-cycle model containing analysis methods such as FMEA, FTA, HAZOP, HW-Metrics, re-engineering of requirements using formal or semi-formal methods where/when possible, and the use of model based approaches for safety assurance analysis including 'safe' code analysis (e.
g. , Tests Generation Tools). A holistic product life cycle approach enables a comprehensive development, considering system dependability issues, and the use of statistics and applied probability approaches (e. g. , stochastic model-checking techniques) confers a measurement approach appropriate to safety, security and performance. Finally the resulting product life cycle approach guarantees the whole software development process integrity with respect the requirements for a safety-critical application. This approach can reuse cross-domain, and skills and knowledge can be used from one domain into others. AQUAS results will impact evolving new standard editions, and communities such as Eclipse/Polarsys.
Performance and dependability IEC TC56, Dependability (formerly: Reliability), has recently issued interesting drafts or standards covering the dependability aspects of systems and open adaptive systems (AIT is member of the national group VE EG56 for IEC TC56): • IEC 62853/Ed1: Open Systems Dependability (CD, comments closed July 2015; it addresses particularly the "assurance case")); • IEC 62628/Ed1: Guidance on Software Aspects of Dependability, • IEC 62741/Ed1: Reliability of systems, equipment and components. Guide to the demonstration of dependability requirements. • The dependability case: this is of importance to AQUAS because the focus is here on general dependability properties and not primarily on safety and security as in IEC TC65 and ISO. Dependability is defined as a quality attribute that "includes availability, reliability, recoverability, maintainability and maintenance support, performance, and, in some cases, other characteristics such as durability, safety and security".
Experience values show that the effort for safety and security verification and validation to reach the required safety and security levels is enormous. Within AQUAS, SSP shall be considered during the development life-cycle by various measures, such as modeling control software in the NMT controller hardware to reduce development time and costs, modeling the patient, applying tools for verification and validation to gain performance evidence in test cases that cover most possible real situations in real life, and securing the communication between the different components making them robust and not prone to compromising the integrity of the system. In this context, important standards are IEEE 11073 [54] (related to the interoperability between medical devices), EN 62304  [55]  (related to software development of medical equipment), and EN 60601-1-10  [56]  (related to closed-loop control systems).
One major goal is to replace legacy design systems with multicore architectures to improve performance. Parallelizable video compression algorithms that are commonly used in space domain will be taken to test the performance of the system. A possible core for the architecture is the LEON3FT  [61]  , which will be used as base to implement the Scalable Sensor Data Processor Breadboard architecture. The use case must support compliance to the European Cooperation for Space Standardization (ECSS) family of standards for Space Software (ECSS-Q-ST-80C  [62]  and ECSS-E-ST-40C  [63]  ). The tools and methods developed in AQUAS should show an impact on certification and validation of the algorithms. Currently, the relevant interaction points are being elaborated in their respective PLC phase and that will potentially lead to tradeoff decisions for the design.
The demonstrator SW is composed by the Boot SW and the Application SW, this last one is the subject of study in AQUAS. A safety-security-co-design was done by code developers, trying to consider during design phase the needed security features with the design of safety-oriented risk mitigation mechanisms. The application software is implemented with a realtime operating system toolchain. The schedulability of the whole software is analyzed with tools specialized on timing analysis in order to check if security features do not negatively influence the performance.