dataesr/scientific-paragraphs-categorization huggingface dataset:
Features abstractly represent assets and are tracked, for instance, in a database or, more formally, in a feature model. Many features also serve as a configuration option (a. k. a. , optional feature). Feature Model. Keeping an overview understanding of features, organizations should create a feature modelan intuitive, tree-like representation of features and their constraints  [99, 58, 6, 141]. The typical graphical notation is shown in Fig. 1 , representing a small excerpt of the Linux kernel's variability model. For brevity, we refer to related work  [33, 32, 29]  for an introduction into feature models and this particular example. SPLE Process. For an organization to effectively engineer a platform, textbook SPLE methods  [12, 150, 57]  introduce two main processes: domain engineering, which aims at engineering the platform, and application engineering, which aims at deriving individual variants from the platform.
We also conducted a lightweight literature study where we collected and inspected meta-studies, surveys, exploratory studies, industrial case studies, and experience reports. Even though, we know from experience that the large majority of these publications focus on praising the benefits of SPLE (e. g. , cost savings and shorter time to markets) while not providing sufficiently detailed data on the adopted concepts and on challenges (i. e. , remaining challenges for SPLE research, as opposed to those that were solved in the case study), we decided to systematically collect those publications and triangulate our synthesized challenges with those from these cases. To collect publications, we used our own expertise as well as we consulted the SPLE community's "Hall of Fame," 1  a book with a collection of successful SPLE cases  [121] , and the Software Engineering Institute's catalog of case studies  [175].
Experience Reports and Case Studies Over the last decades, practitioners and researchers have published a large number of case studies and experience reports, the majority between the end of the 1990s and the beginning of the 2000s. We now list all cases we identified. When available, we provide all references that describe the case in detail. However, some cases were described in the respective source only, not as part of a publication on its own. All the cases in the book of van der Linden et al. [121]  describe successful adoptions of product lines, where usually the typical concepts are adopted (platform, feature modeling, automated product derivation, automated testing); for each, the obstacles and limitations in SPLE are also described. We inspected all the cases: AKVAsmart, Bosch  [187, 179, 183] , DNV Software, Mar-ketMaker  [192] , Nokia Mobile Phones, Nokia Networks, Philips Consumer Electronics Software for Televisions, Philips Medical Systems, Siemens Medical Solutions, and Telvent.
Furthermore, the book also referenced the following cases, each of which we inspected as well: Salion  [43, 52] , Testo  [164] , Axis and Ericsson  [181] , Axis and Securitas  [38, 39] , and RPG Games  [195]  From the SPLE community's "Hall of Fame" 2  we identified and inspected: Boeing  [170] , CelsiusTech Systems AB  [17, 42] , Cummins  [51] , Ericsson Telecommunications Switches, Fiscan Security Inspection Systems  [115] , Hewlett Packard's printer firmwar Owen  [188] , Home-Away  [107] , Lockheed Martin, LSI Logic  [92] , Lucent, Siemens Healthcare  [16] , Toshiba  [128] , U. S. Army  [114] , U. S. Naval Research Laboratory  [17] , General Motors  [78] , and Danfoss  [94, 95, 79]. The cases Salion, Bosch, Market-Maker, Nokia, Philips (Medical Systems and Software for Television Sets) were already contained in the book of van der Linden et al.
[121] , explained above. We inspected all cases of the Software Engineering Institute's catalog of case studies  [175] : US Army's Common Avionics Architecture System (CAAS)  [49] , CCT (Control Channel Toolkit)  [50] , Naval Underwater Warfare Center  [54, 55, 56] , Argon  [35] , ABB  [83, 157, 150, 180] , Deutsche Bank  [75] , Dialect Solutions  [178] , E-COM  [116] , Ericsson  [133, 10] , Enea  [10] , Eurocopter  [63, 91] , Hitachi  [182] , LG  [150] , Lufthansa  [45] , MSI  [169] , NASA  [81] , NASA JPL  [82] , Nortel  [62] , ORisk Consulting  [152] , Overwatch Textron Systems  [93] , Ricoh  [104] , Rockwell Collins  [73] , Rolls-Royce  [86] , TomTom  [174] , and Wikon  [146]. The cases CelsiusTech, Salion  [52] , Axis  [40] , Boeing, Cummins, Danfoss, and DNV Software were already contained in one of the other sources above.
Finally, we also included some cases that we know from our experience are neither contained in the book of van der Linden et al. , the SPLE community's "Hall of Fame" nor the Software Engineering Institute's catalog. These were: six German SMEs (including MarketMaker from above)  [98] , a telecommunication system known as Terrestrial Trunked Radio (TETRA)  [149] , Volvo Cars and Scania  [67, 85] , Audi  [87] , and Daimler  [66, 19].
Variable Artifact Types Not surprisingly, the most frequently mentioned variable artifact is source code as shown in Table  1. Many companies use conditional compilation with preprocessor directives to include variability information in the source code. Custom descriptors are also relatively common, e. g. , as the foundation for code generation. These are often expressed using domain-specific languages. We found little evidence for variability in tests, and requirements. Only one company explicitly reports to use components as variable assets, but we expect that there are many companies that do this implicitly. A use case that is a bit neglected in research is variability in models used for code generation. Five of our subjects write application logic in Simulink and then generate code. Apparently, common variabilitymanagement techniques on the code level are not applicable; instead, variability modeling concepts, especially variation-point support is needed in the models and needs to be supported by the modeling tools.
power electronics (use case) This use case primarily relies on clone & own. Yet, configuration mechanisms in individual variants also exist. The drive software is written in C/C++ and a substantial part of the code is generated from XML files with an in-house generator. The source code contains preprocessor statements controlled by configuration options. Automatic testing of individual variants is in place through a continuous integration system using Jenkins with automated, nightly tests. The connection between customer adaptations and features is tracked in a database to ensure long-term maintainability. Likewise, rationales for variability decisions are recorded. The specific variants are built through a Pythonbased build system that allows component selection. declared over assets 10 a platform of models 11 tool vendor, applies to usage of tool 13 Eclipse features; very high level 14 also unified to some extent 15 for in-component/in-module configuration 16 constraints checking 18 Systems-On-Chip specific quality attributes such as heat dissipation or power consumption.
Truck Manufacturing Use Case This case comprises the software development of a large truck manufacturer. All of its products (80,000 trucks per year) come from the same platform. Almost every product shipped has a unique configuration. The main differentiator of the brand on the global market is full product customizability. The truck manufacturing case relies on an integrated platform to manage variability and employs separate domain and application engineering. All configuration options are realised with configurable values (i. e. , without #ifdef or similar constructs). Features are maintained in a feature database that contains traceability links to the code. Assets (different levels of specifications and source code) are stored in separate databases. Consistency is checked when a system is made ready for release.
The functional components can be configured via static parameters, which are feature-like entities used within variation points relying on conditional compilation (e. g. , with #ifdefs). These parameters are arranged in a relatively flat hierarchy stored in a distributed feature database and allow feature-to-code traceability. Rationales are recorded by tracing feature information to requirements. An informal feature model maps the high-level features and the static parameters. Constraints are defined over the static parameters. Interestingly, these parameters represent both variations and versions, since some of them map to pre-processor macros, and the version-control system directly supports checking out variants. As such, variability and version management are to some extent unified (like in variation control systems  [122, 176, 24] ).
We are [. ] outstanding in managing product variants [. ] Of course there is further potential for improvement and that is what we are seeking. automotive firmware (use case) Also, dynamic (calibration) parameters for late binding exist, some of which can be defined by the customers after delivery. These parameters, including preconditions, are stored in separate databases, upon which experts configure customer adaptations using in-house tools. Configurations are recorded in a special database. Various analyses are run on the distributed feature database, including internal feature consistency checking. An SPLE tool is increasingly used to complement the existing cross-database consistency analyzes with rules and predicates. Single-system performance analysis is done for the products shipped to customers.
Web Application Use Case This case focuses on the creation of web applications that, among others, allow companies to manage media campaigns. Each client receives a customized variant. Different variants are created with clone & own. Each application consists of frontend and backend code and most variability is in the user-facing frontend part of the system, realized using JavaScript and AngularJS. Features are recorded in a highly informal feature model. Otherwise, the company relies on the knowledge of an expert engineer who knows the distribution of features across branches. The system is implemented using different services where a final product is a composition of different services from a core library, product-specific code, and third-party services. The core services can be adapted with calibration parameters in configuration files to achieve specific behavior for each product.
To this end, an integrated software platform based on Eclipse plug-ins is used. All provided solutions share a common set of modules. Because features are localized in specific plug-ins, feature-to-code traceability is available. Currently, the variability in terms of packaging is not managed in a tool-supported way. Variants are composed by component selection, relying on the Eclipse P2 packaging system, which considers constraints between features and plugins, and uses a limited feature model. The configurator defines which modules are part of a package and has limited support to set configuration options for the individual plug-ins. No particular tool is used to manage the variability in terms of packaging. Technically the variability is ensured by the modular design. modeling platform (use case).
Chip Modeling Tool Case This case concerns a tool for designing Systems-on-Chips (SoC) and the reusable hardware component designs from which these SoCs are assembled. These designs are passed to machines that produce the corresponding integrated circuits. The company believes that emerging applications with huge growth potential, such as SoC for IoT will lead to a combinatorial explosion of variants, with features being related via complex trade-off constraints. The variants differ by: their provided functions, execution performance of functions, packaging of SoC inside a circuit, power consumption, safety level (typically determined by standards), and life-cycle durations. The modeling tool is based on the IP-XACT standard (IEEE 1685) and extensions for modeling registers and memory. The integrated software platform currently does not support any specific variability management facilities, nor is it seamlessly integrated with an SPLE tool.
General Challenges Challenge 1, Model-Driven Engineering. A common challenge we observed for any maturity level is modeldriven engineering (MDE) and code generation. While source code is still the most frequently mentioned variable artifact (cf. Sec. 5. 2), we observed that often code is generated from domain-specific languages (DSLs). While the relation between DSLs and SPLE has been studied  [193] , the DSLs used in our cases do not support SPLE concepts. As seen in our power electronics, aerospace, and truck manufacturing cases, embedded systems organizations often rely on MDE using Simulink with code generation. Such a setup challenges not only handling cloned variants (e. g. , when trying to trace features), but also adopting, working with, and evolving an integrated platform  [103]. This observation is substantiated by our three tool cases striving to integrate variability mechanisms into the modeling tools.
Recently, Kr üger et al. [60, 7]  provide datasets and experiences migrating cloned Java and Android game variants to such a common architecture. Challenge 6, Migration Decision Support. A migration process should also provide decision support about the migration itself, based on the expected costs and benefits  [8, 112]. Specifically, for our power electronics case, the suggestion was made to enhance feature identification and location with indicators about the cost of the extraction and re-engineering of relevant assets for making them reusable or integrating into a platform. Cost/Benefit Estimation. The need for effective cost/ benefit estimation is further supported by existing experience reports on Deutsche Bank  [75] , on Philips Medical Systems  [121] , on Hitachi  [182] , on Ericsson  [133, 10] , on Axis and Ericsson  [181] , as as on Axis and Securitas  [38, 39].
Working with an Integrated Platform We observed the following challenges expressed for our use cases and tool cases when dealing with an integrated platform. Challenge 8, Representation of Variability. A need expressed by all cases is a centralized (and ideally unified  [24] ) representation of variability. For instance, for the aerospace and automotive firmware cases, an overall view providing a unified description of the variability was demanded, ideally in the form of a feature model declared in an established SPLE tool. Specifically, in one of these two cases, the variability information is scattered across different representations, including a distributed feature database and configuration files, preventing a coherent view of all relevant product line information. Also recall that many different types of artifacts (e.
This challenge is related to Challenge 1 (MDE and code generation), given that abstract HCI models are sometimes used before the generation of concrete HCI implementations in target languages  [125]. Also note that web applications as cases are rather rare among the existing literature. Exceptions are HomeAway  [107]  and MarketMaker  [192] ; however, none of the publications describes the realization of variability in the web-based user interfaces of these web applications. Challenge 9, Feature Modeling. In the light of obtaining a unified representation of variability, almost all of our subjects (9 of 12) strive to adopt feature modeling. For the power electronics case, a feature model would aim at visualizing the variant space and keeping the variants manageable. For the automotive firmware case, a feature model would be the basis for a configurator with intelligent configuration facilities, which should support product derivation using defaults, choice propagation, and conflict resolution-easing the configuration (and avoiding having to decide all features) Likewise, for the modeling platform case, an improved product derivation through an intelligent configurator tool is needed.
e. , no trace should be visible that a variation point exists) for unauthorized personnel. Unfortunately, beyond work by Faegri et al. [71] , this challenge has not yet been recognized or received attention in the research community. Feature-Oriented Views and Synchronization. For nine of our twelve cases, the need for better visualizations, especially establishing feature-oriented views  [5, 9, 135, 136, 143, 127] , was expressed. In one of our cases it is planned to reverse-engineer feature constraints from the codebase and distributed feature databases, including identifying the model hierarchy  [139, 140] , and to synthesize a feature model. This challenge is also reported by the exploratory study of Chen et al. [46] , and by the survey of Berger et al. [30]. An additional issue arising (related to Challenge 11 below) is that materialized views need to be continuously synchronized with the information sources, including feature databases, which cannot be abandoned.
Validation and Verification. The following two cases explicitly expressed the need for assuring properties for all possible variants (a. k. a. , variability-aware analysis  [130, 117] ). The truck manufacturing case requests safety verification for the widest possible number of variants with a scalable compositional verification approach. Such a compositional verification should verify each lowestlevel component individually, then reuse the results for verifying component combinations, showing that functional or quality properties are fulfilled for large sets of configurations that cannot be tested exhaustively. To this end, source code needs to be annotated with formal specifications, which in turn needs a clear picture of the product lines, especially configuration constraints. In the truck manufacturing case, this requires consolidating information scattered across various databases before.
" Valuable guidelines are provided by Svahnberg et al. [181] , but thorough support is still needed. Our cases face the following challenges. Challenge 11, Artifact Synchronization. The synchronization of different platform artifacts, including code and feature model, was emphasized for half of our cases (railway, aerospace, modeling platform, web application, automotive firmware, and chip modeling). A question that arises is how to keep the feature model in sync, for instance, whether incremental updates or a frequent re-synthesis should be done. Co-evolution scenarios in SPLE have been studied  [90, 166] , but have not yet been adopted in industry. The synchronization challenge is, not surprisingly, further complicated by Challenge 1 (MDE), when models constitute the primary variable artifacts.
As such, organizations have a need to keep track of product variations that have been delivered to customers in their own portfolio. Of course, the question arises how to efficiently store and efficiently keep such customer configuration databases updated. Addressing this challenge would require continuous measurement, perhaps building upon monitoring support  [153] , which needs to be extended and integrated with variability management concepts. Challenge 13, Dynamic Product-Line Platform. An improvement goal expressed for our aerospace case is to conceive its next-generation product-line architecture, which specifically aims at adopting dynamic variability. This challenge is also pointed out in existing experience reports on Enea  [10]  and on Danfoss  [79]. The challenge is to adopt more modern variability mechanisms (supporting late dynamic binding) to support reconfiguration in the aircraft simulator environment.
Conclusion We presented a multiple-case study on the adoption and challenges of systematic variability management in industrial practice, organized in a common framework. Our twelve cases comprised nine use cases, where SPLE concepts are adopted for developing an organization's systems, and three tool cases, representing modeling tools for software and hardware, where the vendor sees a need for adopting SPLE concepts in the tools-enhancing variant-engineering practices among customers. Given that most experience reports  [121]  are more than a decade old and very diverse in terms of details reported, we provided an up-to-date snapshot on as many as twelve cases. With a specific focus on the adoption of concepts organized in a common framework, our work is also the first that systematically elicited this state of adoption from a range of companies-a surprisingly challenging task, given that we needed many iterations to understand the development and thereby also which concepts are used.
Yet, study again shows the need for adoption also in smaller companies, including those in the web application domain. Experience reports and surveys on adoption in such smaller companies  [192, 184, 185]  and strategies for incremental adoption of concepts  [11]  are certainly relevant to consider in future research. Challenges. We observe that the adoption of SPLE concepts is still a tool-integration problem, given all the different types of artifacts and existing tooling, which engineers are familiar with and that is core to the development. How this situation can be improved, and whether there are research questions (as opposed to it being just an engineering problem that tool integrators need to solve), are interesting questions to be answered in the future. Some steps in this direction were taken with the publicly available Common Variability Language proposal  [89] , the Variability Exchange Language  [191] , the recent initiative for a common feature-modeling language (cf.
Lack of ACL/ACS alters the T. gondii metabolome including disruption of FA elongation Analysing ΔACL/iΔACS parasites by IFA and western blot allowed us to conclude that 16 h of Shld-1 removal was sufficient to deplete ACS in the ΔACL/iΔACS strain, while parasites showed no growth defect or morphological abnormalities at this relatively early time point of ACS depletion and remained viable. In the following analyses, iΔACS and ΔACL/iΔACS refer to parasites depleted of ACS by removal of Shld-1 for 16 h. To obtain a global picture of the impact of the loss of nucleo-cytosolic acetyl-CoA on parasite metabolism, we performed untargeted metabolomics using liquid chromatography-mass spectrometry (LC-MS). The full dataset is available in a data repository  [24]. Over 850 putative metabolites were detected, and the relative abundance of all metabolites was compared to that of RH parasites (Additional file 2: Table  S1 ).
Most sites (142) were hypo-acetylated while 40 were hyperacetylated in ΔACL/iΔACS parasites (Fig. 4a ). The predominant hypo-acetylation (78% of differentially acetylated sites) is consistent with the expected reduction of acetyl-CoA. The complete dataset is available in a data repository  [28]. To determine the sub-cellular localisation of differentially acetylated proteins, we predicted their putative localisation based on the hyperplexed Localisation of Organelle Proteins by Isotopic Tagging (hyperLOPIT) data available under https://proteome. shinyapps. io/toxolopittzex/ and on ToxoDB (https://toxodb. org) [27]. For simplification, we merged some of the sub-cellular compartments (19S proteasome/20S proteasome/40S ribosome/60S ribosome/cytosol into cytosol; nucleolus/ nucleuschromatin/nucleus non-chromatin into nucleus and mitochondrion membranes/mitochondrion soluble into mitochondrion etc.