476 American Academic Scientific Research Journal for Engineering, Technology, and Sciences ISSN (Print) 2313-4410, ISSN (Online) 2313-4402 http://asrjetsjournal.org/ Onto4CAAL: An Ontology to Support Requirements Specification in the Development of AAL (Ambient Assisted Living) Systems Timóteo G. Silva a *, Fernanda Alencar b a,b Federal University of Pernambuco (UFPE) -Graduate Program in Electrical Engineering (PPGEE/UFPE), Electronics and Systems Department, 50.740-560, Recife – Brazil a Email: timoteogomes@yahoo.com.br, b Email: fernandaalenc@gmail.com Abstract The Ambient Assisted Living (AAL) is a technological approach that emerged to meet the demands of the elderly and people with disabilities. As they are considered complex and multidisciplinary systems, it is necessary to identify and define which modules need to compose these systems. Among the challenges found in the development of the AAL systems are the alignment with functional and/or non-functional requirements and the compliance with ethical, legal, social, medical and technical restrictions that guide these types of systems. Therefore, this work presents a core ontology (Onto4CAAL) to support the specification of requirements in AAL systems, where the elements that are part of the system type are integrated. Using this ontology, it was possible to develop a domain ontology (Onto4Elev) for Vertical Lift Platforms, where a validation was carried out with the industry in relation to the elements that constitute it and, later, a scenario was built for the application simulation and verification. With the use of ontology, it will be possible to standardize the understanding of the associated terms and, at the same time, to verify the relationship among the elements, helping the designer in the decision making. Keywords: Compliance; Requirements Specification; Ontology; AAL Systems. 1. Introduction According to [1], in the last decade, intelligent environments, or assisted living environments (AAL), have found wide application in various contexts, such as home automation, education, rehabilitation and others, considering that the implementation of new technologies can improve the quality of everyday life, to facilitate access to many functions remotely, or to enable the use of natural interfaces, such as gestures and voice, to control lighting, climate, entertainment systems and home appliances. ------------------------------------------------------------------------ * Corresponding author. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 477 According to Vimarlund [2], the global market for AAL is currently expected to reach up to 13.74 billion dollars by 2027, influenced by the emergence of COVID-19, increasing pressure from the need of providing virtual services, where AAL technologies are being considered a long-term solution to deliver healthcare during the current pandemic and in the future. Therefore, as the population ages, new policies, systems and technologies are demanded to support healthy aging, where new technologies can be used to accompany the elderly in order to reduce daily physical assistance and to prolong their independent life [Program AAL]. However, there are several engineering challenges to be faced in the development of AAL systems, as these systems require standardized interfaces, they are also multidisciplinary, adaptable to context and self-integrating, and must be aligned with compliance requirements [4], all this associated with the inadequacy of current engineering methods and research approaches complicate the process of developing AAL systems [5]. Furthermore, in recent years, the complexity and scale of compliance requirements have increased significantly due to globalization and the maturing of different fields and legal requirements, making it difficult to meet ethical, legal, social, medical and technical constraints, knowing that these must be brought together and consolidated into a requirements specification [4]. These challenges in developing AAL systems have led the academic community to explore and to establish original approaches to the development of these systems [1] and to integrate them into different areas of knowledge, where we can mention two of them: compliance and ontology. In this context, we searched the literature for evidence on the use of ontologies for the development of AAL systems [6] and, from the evidence gathered in the literature and through a survey carried out with experts, a model was built in the UML notation of a core ontology (Onto4CAAL) to support the specification of requirements for AAL systems [7], as well as a domain ontology for vertical lifting platform (Onto4Elev), both presented in this work. The work is structured as follows: Section 2 introduces the concepts of Ambient Assisted Living (AAL), Ontology, Compliance and Requirements Engineering for AAL Systems; in Section 3, the Onto4CAAL ontology proposal is presented; Section 4 shows the Onto4Elev domain ontology and its application in a simulation in a use case; in Section 5 the related works are lodged; in Section 6 limitations and future work are listed; in Section 7 the conclusions are mentioned. 2. Theoretical Reference In this section we present the basic knowledge used to understand the theme involved in this work. 2.1. AAL Systems The Ambient Assisted Living (AAL) is an approach, based on technological solutions, which emerged to positively influence the health and quality of life of people, especially the elderly ones [8]. An assisted living environment (ALA) is an integration of autonomous assistive technologies, solutions and American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 478 services that can positively influence people's health and quality of life, especially the elderly ones. Technologies for AAL can be provided in the form of smart homes, equipped with sensors to monitor the different conditions of the environment and their inhabitants, and actuators to effectively assist them in their daily activities [9]. In summary, AAL characterizes an automated environment in which users interact with physical objects. Systems for AAL need to know data about the world around the users they monitor to perform actions and perceive the context and modules that make up the entire environment [10]. Given this perspective, both what was pointed out by Nakagawa [11] back early in 2013, and ratified by Cicirelli [1], the premise that AAL systems have become an increasingly important multidisciplinary research topic for medical and technological research communities remains valid. 2.2. Ontology In the mid-1990s, in the context of Information Science, ontology emerged [12], and the most accepted definition was the one developed by Gruber [13], who describes it as an explicit specification of a conceptualization. In computing, the ontology aims to facilitate the sharing and reuse of information [14], in addition to define a conceptual specification for “the knowledge” of a given domain. Thus, Campos [15] considers that ontologies establish a common vocabulary for a community that needs to share information in each domain, so that definitions can be computationally interpretable and include representations of concepts and relationships. It is also worth noting that ontologies are systems of organization and representation of knowledge of a given domain in the form of a relational, intentional network, where relationships overlap with possible “state of affairs” [16]. That is why ontologies are commonly used to formalize and to explicitly specify a domain of knowledge, as they improve the automation of the integration of heterogeneous data groups, providing a formal specification of the vocabulary of concepts and their relationships [17]. 2.3. Compliance Compliance comes from the English language. “To Comply” means “to fulfill”, “satisfy”, “to carry out what has been imposed on it, in terms of the duty to comply, to comply with the legislation and regulations applicable to the business, codes of ethics and policies of the institution, as well as enforcing internal and external regulations imposed on the institution's activities [18]. NBR ISO 19600 [19] conceptualizes compliance as a set of mechanisms that aims to meet standards, policies and guidelines of a business. According to Zhong [20], the construction phase of a system is ruled by many regulations, and it is important to inspect the construction process according to the regulations (called compliance verification or inspection) to ensure quality. Numerous works have addressed compliance as an initial requirement of the system, taking the rights of the law as the objectives of the systems to be satisfied and, therefore, aligning requirements engineering with compliance techniques [21]. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 479 In recent years, the complexity and scale of compliance requirements have increased significantly due to globalization, as the requests of regulations, standards and frameworks increase in number and scope, as the maturing process of different fields and regulations also increases as the areas or domains they cover become more interconnected [4]. 2.4. Requirements Specification for AAL Systems The requirements specification has as its main objective to obtain relevant information to the development of the system. For Abran [22], it is the first stage of understanding construction the of the problem to be solved by the system, strictly marked by human action in the relationships established between the development team and the client. According to Carvalho [23] most of the problems encountered during the development of systems originate in the requirements specification stage, because if the interested parties do not always have the clarity of what they need, it is not simple for the requirements analyst to be able to define which aspects are relevant to stakeholders. In the last decade, several research papers have addressed the development of AAL systems and health systems. Such systems are considered sensitive and critical; they also often obey specific constraints and verification of their correctness requires the use, at least partially, of formal approaches [24]. According to Alosaimi [25], knowing that AAL systems are designed for customized, responsive and predictive requirements, demanding high functionality performance to ensure interoperability, accessibility, security and consistency. Also, according to Alosaimi [25], standardization, continuity and assistance to systems development have become an urgent need to meet the growing needs of sustainable systems. Thus, we can see that the approaches to build AAL systems that ensure that the requirements are met and the verification tools that prove that the system implementation meets the system requirements are still in their design phase, since there are few works in the literature on development methodologies to improve the reliability and correction of these systems, but not focusing on the initial phase of the construction of such systems. Some examples were the ones proposed by Augusto [26], about the application of methods and verification tools that are used in other Computer Science fields to develop AAL systems, such as the one proposed by Erazo-Garzon [27], which comes up with a quality-in-use model for AAL systems focused on the following characteristics: effectiveness, efficiency, fulfillment, risk exemption and context coverage. As a result, there is still, in fact, a lack of solutions capable of supporting designers in the initial stage of development of such systems. This is necessary in order to follow what it had already been said by Nehmer [28], where the author states that without an appropriate methodology for the specification and development of AAL systems, it will never be possible to build reliable life care systems [28]. Thereby, we have the ontology, which can be used to assist in specifying the requirements of AAL systems, as it presents a formality to represent the internal concepts of the domain and the relationships between them, as well as it can incorporate the regulatory aspects of these types of systems. The formal specification of the behavior of the system and the requirements (with the NFRs) that the system must meet improve the development process and allow the verification of these systems [4]. Therefore, a core ontology (Onto4CAAL) was proposed to support the specification of requirements for AAL systems. The ontology will be presented in the next section. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 480 3. Onto4CAAL Ontology Proposal Onto4CAAL is a core ontology that comprises a formal definition of modules and requirements for AAL systems. It includes aspects of compliance, NFRs (quality, product and ethical requirements), devices, environments, stakeholders and types of systems, as well as the relationships among these elements, which can contribute to the specification process of this type of system. Towards ontology development, since there is no standardization of an ontology development process [29], there are, however, several ontology development methodologies provided in literature. For the development of Onto4CAAL, the Methontology methodology was chosen [ 30], as it is used and recommended by the Foundation for Intelligent Physical Agents (FIPA), in addition of being considered a mature methodology. The steps suggested by Methontology, which were used in the development of Onto4CALL, are: specification, knowledge acquisition, conceptualization, formalization, integration, implementation, evaluation, documentation and maintenance. For the Specification stage, which is a stage where natural language is used, containing information as the main objective of the ontology and its other purposes, 12 Competency Questions were elaborated. In the next step, which is Knowledge Acquisition, we used the articles found in the MSL [6] and a first survey conducted with experts from both the academic and industrial fields. For this step, the middle out approach [31] was used, since it allows a balance in terms of the level of detail, allowing the identification of central concepts of the knowledge domain, and then these concepts were generalized and specialized to produce the ontology. For the Conceptualization stage, a glossary of terms was made, gathering useful and potentially usable domain knowledge and their respective meanings. In the Formalization step, axiomatization was used, which is illustrated through UML notation, and formalized by axioms in descriptive logic (DL). Therefore, concepts are considered as UML classes, relationships assume the role of inheritance and associations, and instances are described through object diagrams. Next, the UML notation is presented (in point A) and, later, the formalization by axioms (in point B). 3.1. Onto4CAAL UML Notation The link (https://github.com/timoteogomes/Onto4CAAL.git ) presents the modeling of all modules associated with AAL, Compliance and Non-Functional Requirements systems, where the suggestions proposed by the survey respondents were considered (the additions from the survey are highlighted within the boxes with dotted red borders). This modeling was performed using the principle of UFO (ontology of foundation) proposed by Guizzardi [32] and modeled by OntoUML [33], using a plugin of the Visual Paradigm tool. 3.2. Tables with Axioms Below there are some of the axioms (Onto4CAAL has 545 axioms) of the six modules into which Onto4CAAL were divided, that is: AAL Systems, Compliance, Requirement, Stakeholder, Environment and Device. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 481  Axioms of ALL Systems Table 1 presents 3 (three) of the axioms established for the AAL systems module and their relationships with the other Onto4CAAL modules. Among the axioms that are presented, we have both concept and relation axioms. The axiom “AALSystems ⊑ ∃ usedIn.Environment”, for example, is an existential relation axiom (∃), that it represents those instances that are AAL System used in at least one Environment instance. Table 1: AAL systems axioms. Representation Axioms 𝒯A AALSystems ≡ EmergencyTreatmentServices ⊔ ComfortServices ⊔ AutonomyEnhancementServices InternalAssistanceComfort ≡ ServicesFindingThings ⊔ InfotainmentServices ⊔ LogisticServices ⊔ PersonalMonitoringServices AALSystems ⊑ ∃usedIn. Environment  Compliance Axioms Table 2 presents 3 (three) axioms established for the Compliance module and their relationships with the other modules of Onto4CAAL. The axiom “InternalStandardsPolicies ⊑ ¬ Legislation” , for example, represents that Legislation instances are disjoint from Legislation instances (?). Table 2: Compliance axioms. Representation Axioms 𝒯C Compliance ≡ Legislation ⊔ ExternalStandards ⊔ InternalStandardsPolicies InternalStandardsPolicies ⊑ ¬ Legislation Compliance ⊑ ∀ establishesNFRequirement.NonFunctionalRequirement  Requirement Axioms Table 3 presents 3 (three) axioms of those established for the Requirement module and their relationships with the other modules of Onto4CAAL. The axiom "Requirement ≡ NonFunctionalRequirement ⊔ FunctionalRequirement", for example, represents the set of Requirements formed by instances of the concepts NonFunctionalRequirement or FunctionalRequirement. Table 3: Requirement axioms. Representation Axioms 𝒯R Requirement ≡ NonFunctionalRequirement ⊔ FunctionalRequirement ProductQuality ≡ Security ⊔ FunctionalAptitude ⊔ Portability ⊔ EfficiencyPerformance ⊔ Usability ⊔ Adaptivity ⊔ Maintainability ⊔ Compatibility ⊔ Reliability ⊔ Traceability ⊔ PrivacyData Requirement ⊑ ∃wasDefinedBy.Stakeholder  Stakeholder Axioms American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 482 Table 4 presents 3 (three) axioms established for the Stakeholder module and its relations with the other modules of Onto4CAAL. The axiom “Stakeholder ⊑ ∃defines. Requirement” , for example, is an existential relation axiom (∃), where it represents that Stakeholder instances define at least one Requirement instance. Table 4: Stakeholder axioms. Representation Axioms 𝒯S MemberTimeDev ⊑ People ⊓ Stakeholder ProfessionalHealth ⊑ People ⊓ Stakeholder Stakeholder ⊑ ∃defines. Requirement  Environment Axioms Table 5 presents 3 (three) axioms established for the Environment module and their relationships with the others Onto4CAAL modules. The axiom "LongStayElderlyInstitution ≡ GeriatricHouse ⊔ MedicalHousing ⊔ Asylum", for example, represents the set of Long Stay Elderly Institutions formed by instances of the concepts GeriatricHouse or MedicalHousingt or Asylum. Table 5: Environment axioms. Representation Axioms 𝒯E Hospital ⊑ Environment LongStayElderlyInstitution ≡ GeriatricHouse ⊔ MedicalHousing ⊔ Asylum Environment ⊑ ∃ has.AALSystem  Device Axioms Table 6 presents 3 (three) axioms established for the Device module and their relationships with the other Onto4CAAL modules. The axiom "WearableDevice ⊑ Device", for example, represents that the set of WearableDevice instances belong to Device instances, since an inclusion property (⊑) is used. Table 6: Device axioms. Representation Axioms 𝒯D Device ≡ Button ⊔ Display ⊔ Sensor ⊔ Valve ⊔ SignalDevices ⊔ WearableDevice ⊔ Smartphone ⊔ CommandByVoice ⊔ Camera ⊔ Switches ⊔ Actuator⊔ Container ⊔ SoundBox WearableDevice ⊑ Device Device ⊑ ∃ isUsedBy.AALSystem 3.3. Creation of the Onto4CAAL Ontology in Protégé Protégé is an open source application for creating and editing ontologies, offering a graphical interface and architecture for creating knowledge-based tools. The version used for this work was 5.5.0. Therefore, Onto4CAAL was built, where it is possible to see in Figure 1 that, in addition to the 545 axioms, there are also 189 classes, thirty-three object properties, and five data properties. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 483 In Figure 2, the image that represents the part of the relations in the form of expression is presented, where it is presented, in the case of the AALSystems class, that it has some device, has a requirement, is used in some environment and is influenced by compliance. In Figure 3, it is possible to notice the six modules defined for the composition of Onto4CAAL, highlighting the AALSystems module, which consists of the EmergencyTreatmentServices, ComfortServices and Autonomy EnhancementServices classes, in addition to the subclasses of each one of them. It is still possible to see in the same figure the Requirement module, which is expanded, and it was composed by the FunctionalRequirement and NonFunctionalRequirement classes, and within this, the EthicalRequirement and RequirementQuality classes. This class is where the ProductQuality and QualityUse subclasses are housed. Figure 1: Onto4CAAL ontology metrics in the Protegé tool. Figure 2: AALSytems Class Relation. Figure 3: Class hierarchy of the Onto4CAAL ontology in the Protegé tool. 4. Domain Ontology (ONTO4ELEV) One of the characteristics of central ontologies is the possibility of their reuse to create domain ontologies. Considering that AAL systems have several classifications and subtypes, the existence of a central ontology allows the application for the development of specific ontologies. As a demonstration of the possibility of reusing the Onto4CAAL ontology, a domain ontology for the vertical elevation platform (Onto4Elev) was proposed, which is one of the numerous applications associated with American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 484 transport-type AAL systems. This type is one of the subclassifications of the systems associated with Services of Comfort, according to the Nehmer classification [28]. Onto4Elev is a domain ontology that inherited several classes from Onto4CAAL, as can be seen in the image contained in GITHUB. Due to the specificity of vertical lifting platforms (PEV), it was necessary to investigate the Literature to find which elements should be considered for the construction of a PEV, which are those highlighted with the edge of the class in green in Figure 4. To verify/validate the elements that were raised in the literature and initially proposed to compose the Onto4Elev ontology. A survey was carried out with professionals working in the PEV construction industry [34]. Next, we will see about the UML notation of Onto4Elev and the axioms resulting from the extension of Onto4CAAL to the domain of PEVs: 4.1. Survey for Verification/Validation of Onto4Elev Elements The target audience of this survey was professionals from the Brazilian industry who work with ENP development. For this, a survey was conducted with several Brazilian companies (18 in total), as well as professionals who work in these companies (via LinkedIn). For application and data collection, a questionnaire was used, prepared through the online tool QuestionPro, consisting of 7 (seven) questions and accessed through the link (https://questionpro.com/t/ATQIUZsqND). Seven respondents answered the survey, four of them from the technical area, two are business owners and 1 is from the commercial area. As a result, there were contributions in the elements associated with Application Environments of PEV's, Mechanical Components, Electrical Devices, Signaling and Stakeholders. 4.2. Onto4Elev UML Notation The image contained in the link (https://github.com/timoteogomes/Onto4Elev.git) presents the complete modeling of all modules associated with PEV-type AAL systems, where it is possible to identify both elements that were added through the collection of information in the literature (these are the ones with the classes in green), and those that were added as a result of the survey, which are the ones that are hatched with blue dots. The elements represented by the classes with the black borders are the ones that were inherited from Onto4CAAL. Hereafter, we will highlight the adaptations that occurred in Onto4CAAL to enable the construction of Onto4Elev, associating each image with the type of element that was adjusted.  Types of Environments As described in Figure 4 caption, it is possible to see that there was an aggregation of types of application environments for the PEVs, with their emphasis on the external context (public and commercial places). American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 485 Figure 4: Modeling of the Environment class of the Onto4Elev ontology (built in the VisualParadigm tool).  Mechanical Components For the PEV-type AAL system, the Mechanical Components element was added to Onto4Elev, making it possible to notice that this element, as shown in Figure 5, is not part of the constitution of the central ontology, that is, of Onto4CAAL, but it has several components that are used in the construction of PEVs and that need to be considered when specifying the requirements. Figure 5: Modeling of the MechanicalComponent class of the Onto4Elev ontology (built in the VisualParadigm tool).  Electrical Devices and Signaling Regarding electrical devices, according to Figure 6, several new sub-elements were added, such as the platform control device, which is something specific to this type of systems. For the PEV type AAL system, the Signaling type element was added to Onto4Elev, making it possible to notice that this element, as shown in Figure 6, is not American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 486 part of the constitution of the central ontology, that is, of Onto4CAAL, but it is extremely important in the context of the PEVs. Figure 6: Modeling the ElectricDevice and Signaling classes of the Onto4Elev ontology (built in the VisualParadigm tool).  Stakeholders Regarding the stakeholders, according to Figure 7, several new sub-elements were added, such as the Architect and the Civil Engineer, where both can participate in the construction project of a PEV, as well as the role of the Operator, precisely due to the specificity of this type of AAL system.  Requirements Regarding the requirements, it is important to highlight that, even with the literature research, as well as with the application of the survey with experts from the PEV manufacturing industry, those contained in Onto4CAAL meet the context of Onto4Elev. This demonstrates the completeness of Garces' taxonomy [35]. Figure 7: Modeling of the Stakeholder class of the Onto4Elev ontology (built in the VisualParadigm tool). American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 487  Compliance Regarding compliance-related issues, according to Figure 8, several regulatory standards were added and must be considered, taking into consideration the context in Brazil, when building PEVs, such as the NBR 9050 Standards (accessibility to buildings, furniture, spaces and urban equipment) which deal with accessibility issues and the NBR ISO 9386-1 (Powered lifting platforms for people with reduced mobility) that addresses safety and operating requirements. Figure 8: Modeling of the Compliance class of the Onto4Elev ontology (built in the VisualParadigm tool). 4.3. Onto4Elev Axioms Next, some of the axioms of Onto4Elev that were incorporated to the others inherited from Onto4CAAL are presented.  Axioms of Environment Types Table 7 presents the inclusion of axioms established for the environment types module in the context of Onto4Elev. Among the axioms that are presented, we have the “PublicPlaces ≡ Churches ⊔ PublicOffices”, which represents the set of public places, which is formed by the Churches or PublicOffices instances. Table 7: Environment axioms (ONTO4ELEV) Representation Axioms 𝒯E Environment ≡ CommercialEnvironments ⊔ House ⊔ LongStayElderlyInstitution ⊔ PublicPlaces CommercialEnvironments ≡ Airports ⊔ Banks ⊔ Clinics ⊔ Pharmacies ⊔ Restaurants ⊔ Supermarkets PublicPlaces ≡ Churches ⊔ PublicOffices  Axioms of Mechanical Components American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 488 Table 8 presents 2 (two) axioms among those established for the Mechanical Components module in the Onto4Elev ontology. The axiom “Valve ≡ ValveFall ⊔ PressureReliefValve ⊔ ValveSenseDown”, for example, represents the set of possible instances of the Valve component, which is one of the possible instances of the Mechanical Components element. Table 8: Mechanical component axioms (ONTO4ELEV). Representation Axioms 𝒯MC MechanicalComponent ≡ Key ⊔ Barrier ⊔ SafetyBrake ⊔ Guides ⊔ RackDrive ⊔ GearWheel ⊔ Pinion ⊔ MechanicalBlockingDevice ⊔ Gear ⊔ Bearing ⊔ Sow ⊔ Chain ⊔ Valve ⊔ EnclosedBox ⊔ SpindleTrigger ⊔ ProtectorSill ⊔ HydraulicPiston ⊔ CentralHydraulic Valve ≡ ValveFall ⊔ PressureReliefValve ⊔ ValveSenseDown  Axioms of Electrical Devices Table 9 presents one of the axioms established for the Electrical Devices module, and it is possible to see that several devices were added as instances of this module, such as the "Switch Loosening Cable Current", which occurred due to the specific characteristics of the systems of the type PEV. Table 9: Electricdevice axioms (ONTO4ELEV). Representation Axioms 𝒯ED ElectricDevice ≡ CommandByVoice ⊔ Camera ⊔ InverterFrequency ⊔ LedLamps ⊔ Button ⊔ Autosafe ⊔ Display ⊔ Sensor ⊔ DeviceControlPlatform ⊔ Switches ⊔ StopSwitch ⊔ Actuator ⊔ Intercom ⊔ SafetySwitch ⊔ ContactorRelay ⊔ SwitchLooseningCableCurrent ⊔ LimiterSpeed ⊔ LimitingKeyFinalPercourse ⊔ ElectronicCurtainSecurity  Stakeholder Axioms Table 10 presents 3 (three) axioms among those established for the Onto4Elev Stakeholder module. The axiom “FinalUser ≡ Handicapped ⊔ Elderly”, for example, is an axiom that represents the set of possible instances of the UserFinal component, where, given the specificity of the VEP's, there was the inclusion of two possible end users, which are the elderly and the ones with disabilities. Table 10: Stakeholders axioms (ONTO4ELEV). Representation Axioms 𝒯S People ≡ MemberTimeDev ⊔ FinalUser ⊔ Operator ⊔ Caregiver ⊔ Domestic Companion ⊔ Familiar MemberTimeDev ≡ CivilEngineer ⊔ MechanicalEngineer ⊔ Architect FinalUser ≡ Handicapped ⊔ Elderly  Signaling Axioms Table 11 presents 3 (three) axioms established for the Onto4Elev Signaling module. The axiom "Signaling ≡ Braille ⊔ Sound", for example, represents the set of instances for Signaling, highlighting that this module was American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 489 created for the context of Onto4Elev, that is, it does not originally belong to the central ontology Onto4CAAL. Table 11: Signaling axioms (ONTO4ELEV). Representation Axioms 𝒯Si Signaling ≡ Braille ⊔ Sound Braille ⊑ Signaling Sound ⊑ Signaling 5. Case Study In this section we lodge the application of a case study where the requirements are used in the development of AAL systems of the Vertical Lift Platforms type, knowing that these requirements were extracted from the literature [36]. The case study aims to demonstrate the suitability of the application ontology for Vertical Elevation Platforms, Onto4Elev. 5.1. Scenario The Onto4Elev ontology was instantiated with requirements of a mechanical design of a motorized lifting platform for people with reduced mobility, proposed by Gomes [36]. In the work, he proposed several specific requirements for the construction of this platform. According to Gomes [36], there are several Standards that apply to the design of elevators and platforms, such as: NBR 12892 (Design, manufacture and installation of a single-family elevator), NBR 16042 (Electric passenger elevators) and NBR 9386-1 (Platforms lifts for people with reduced mobility), the latter being the one used in the proposed project and the one applied in this scenario. The platform proposed in the project was the spindle drive type, which is one of the eight types for this type of platform. 5.2. Requirements After analysing the project proposed by Gomes [36], 16 requirements were elicted, contained in Table 12, where each one received an identifier, in addition to the description and type, based on the Onto4Elev Requirements Module. American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 490 Table 12: Requirements case tudy. Requerimet Description Type REQ-1 PEV must have a maximum speed of 0,15 m/s Security → Integrity REQ-2 The minimum flat dimensions of the PEV for the adopted use, which was the cabin with a companion standing behind the wheelchair user, is 800 x 1600 mm (width x length) Usability → Adequacy REQ-3 According to ABNT NBR ISO 9386- 1:2013, equipment must have ways to stop Reliability → ToleranceError REQ-4 PEV must have a normally closed electromagnetic brake Performance efficiency → UseResource REQ-5 PEV must have brake against failure of the drive system Reliability → Recoverability REQ-6 PEV must have a motor starter controlled by a frequency inverter Performance efficiency → UseResource REQ-7 The ABNT NBR ISO 9386-1:2013 standard defines that the safety factor for all parts of the equipment must be greater than or equal to 1.6. For this project the defined factor was 7 Security → Responsibility REQ-8 PEV floor covering must be non-slip Risk-free → MitigationHealthRisksSafety REQ-9 PEV bearing must be replaced every 3 years Maintainability → Modibility REQ-10 The nominal load considered for the PEV must be 2453 N Performance efficiency → capacity REQ-11 Life expectancy of the PEV was defined for a daily use of 1h in 10 years, resulting in 3.650 hours Performance efficiency → BehaviorTime REQ-12 PEV deployed by spindle must have a safety nut, which is coupled to the nut and aim to prevent an uncontrolled fall of the nut onto the spindle Reliability → ToleranceError REQ-13 PEV will have the up and down buttons inside the platform, in addition to the call buttons on both floors Usability → UserOperability REQ-14 PEV will have three types of buttons according to NBR9386-1 [15]: operation buttons, emergency alarm and emergency stop Usability → UserOperability REQ-15 Each floor will feature a call button and a protected emergency button Usability → UserOperability REQ-16 According to the NBR 9386-1 standard, it is necessary to ensure that the button is kept pressed during the entire trip Usability → ProtectionAgainstUserErrors 5.3. Onto4Elev Ontology Simulation in Protegé In order to instantiate Onto4Elev and simulate the established scenario, the Protégé tool (version 5.5.0) was used, which is an open source application for creating and editing ontologies, offering a graphical interface and an architecture for creating knowledge-based tools, with Onto4Elev built, as shown in Figure 9, where the classes created in that tool are demonstrated. It is possible to see in Figure 9 the six modules defined for the composition of Onto4CAAL, highlighting the AALSystems module, which consists of the American Academic Scientific Research Journal for Engineering, Technology, and Sciences(ASRJETS)(2022) Volume 90, No 1, pp 476-500 491 EmergencyTreatmentServices, ComfortServices and Autonomy EnhancementServices classes, in addition to the subclasses of each one of them. After the inclusion of the classes, properties and axioms were also added. As can be seen in Figure 10, there are also 196 classes, in addition to the 650 axioms, twenty-eight object properties, and seven data properties. Then, the Onto4Elev instantiation was performed, inserting the requirements contained in Table 12, where at the end, the coherence and consistency test was performed, using the HermiT reasoner (version 1.4.3) and Pellet, both native to Protégé. Figure 11 demonstrates that Onto4Elev is consistent and coherent, thus being considered an operational ontology. Figures 12, 13 and 14 present the results of simulations in Descriptive Logic (DL) queries. In Figure 12, it is possible to notice that when executing the test to evaluate the return of the Stakeholder Class, we can verify that two actors were inserted (Davi, Túlio), where Túlio is selected and informed that he is a Mechanical Engineer Stakeholder and that he defined the requirements REQ-1, REQ-3, REQ-4, REQ-5, REQ-6, REQ-7, REQ-8, REQ-9, REQ-10, REQ-11, REQ-12, REQ-13, REQ-14, REQ-15 and REQ-16. In Figure 13, we can see that the NBR ISO 9386-1 Standard was instantiated in the Compliance Class, which is of the NBR type, and it is a Standard that has influence on the requirements REQ-3, REQ-7, REQ-14 and REQ -16. Still dealing with the query by DL, it is possible to see in Figure 14 the result of the query to the Requirement Class, where all 16 requirements contained in Table 12 are returned, in addition of being possible to identify that the REQ-7 was defined by the stakeholder Túlio and that this requirement is influenced by the NBR ISO 9386-1 Standard. Figure 15 shows the presentation of existing relationships with REQ-7. This shows the usefulness in traceability when using Ontology with the support of an editor, such as Protegé. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 492 Figure 9: Onto4Elev ontology metrics in the Protegé tool. Figure 10: Onto4Elev ontology metrics in the Protegé tool. Figure 11: Onto4Elev consistency and coherence demo screen. Figure 12: DL Query Screen for Stakeholder class. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 493 Figure 13: DL Query Screen for Compliance class. 5.4. Description of the Onto4Elev ontology simulation in ABox form Then, the real scenario is presented in ABox form to illustrate the simulation performed by the Protégé tool. For the evaluated scenario, we highlight the input and the inferences obtained.  ABox of Scenario 1: Table 13 presents the instances of the domain scenario of the Vertical Lift Platform project. Table 14 presents the ABox of inferences made for Scenario 1. These inferences aim to validate the Onto4Elev ontology to demonstrate its suitability for the domain of Vertical Elevation Platforms. Figure 14: DL Query Screen for Requirement class. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 494 Figure 15: REQ-7 Explanation Screen and its Relationships. It is important to note that the results of the inferences will be presented in ABox. In this process, we consider the axioms presented in table 13 and the terminological axioms laid out in the Onto4CAAL and Onto4Elev Ontologies. Table 13: Abox Instances Scenario 1. Scenario Instances 𝒜c1 AAL(PEV-Demo) System, Software(software-control), Hardware(EmergencyButton- ChampionType), Ambient (Home), usedAt(home), uses(software-control), holds( EmergencyButton - ChampionType), Compliance (NBR_ISO_9386-1), influence (REQ-3, REQ-7, REQ-14, REQ-16), Requirement(REQ-1), Requirement (REQ- 2), Requirement (REQ-3), Requirement (REQ-4), Requirement (REQ- 5), Requirement (REQ-6), Requirement o(REQ-7), Requirement (REQ- 8), Requirement (REQ-9), Requirement (REQ-10), Requirement (REQ- 11), Requirement (REQ-12), Requirement (REQ-13), Requirement (REQ-14), Requirement (REQ-15), Requirement (REQ-16), define(Tulio, REQ-1), define(Davi, REQ-2), define(Tulio, REQ-3), define(Tulio, REQ- 4), define(Tulio, REQ-5), define(Tulio, REQ-6), define(Tulio, REQ-7), define(Tulio, REQ-8), define(Tulio, REQ-9), define(Tulio, REQ-10), define(Tulio, REQ-11), define(Tulio, REQ-12), define(Tulio, REQ-13), define(Tulio, REQ-14), define(Tulio, REQ-15), define(Tulio, REQ-16), Requires(PEV-Demo, REQ-1), Requires(PEV-Demo, REQ-2), Requires(PEV-Demo, REQ-3), Requires (PEV-Demo, REQ-4), Requires (PEV-Demo, REQ-5), Requires (PEV-Demo, REQ-6), Requires (PEV- Demo, REQ-7), Requires (PEV-Demo, REQ-8), Requires (PEV-Demo, REQ-9), Requires (PEV-Demo, REQ-10), Requires (PEV-Demo, REQ- 11), temRequisito(PEV-Demo, REQ-12), Requires (PEV-Demo, REQ- 13), Requires (PEV-Demo, REQ-14), Requires (PEV-Demo, REQ-15) , Requires (PEV-Demo, REQ-16), causesPositiveImpact(REQ-14, REQ- 15), causesPositiveImpact(REQ-16, REQ-15). American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 495 As shown in Table 14, in these first inferences, we have that Tulio and Davi meet the necessary conditions to be considered a Stakeholder, because, according to the axioms of Onto4CAAL, it is considered a Stakeholder when it defines some requirement. It is also possible to infer each Stakeholder defines some requirements, namely: Tulio – REQ-1, REQ-3, REQ-4, REQ-5, REQ-6, REQ-7, REQ-8, REQ-9, REQ-10, REQ-11, REQ-12, REQ-13, REQ-14, REQ-15 and REQ-16 (1) Davi – REQ-2 (2) As shown in Table 15, the resources presented are considered resources of a PEV. Therefore, according to the axioms of Onto4CAAL, PEV-Demo is considered an AAL System because it is used in an Environment, it has a Hardware, it uses a Software and it has Requirements. According to Table 16, we can infer that REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ-6, REQ-7, REQ-8, REQ-9, REQ-10, REQ-11, REQ-12, REQ-13, REQ-14, REQ-15 and REQ-16 are PEV-Demo system requirements. According to the inference from Table 17, a Standard influences the AAL system (PEV-Demo). The defined Standard is NBR_ISO_9386-1, this Standard deals precisely with the safety requirements, dimensions and functional operation of vertical lifting platforms. Table 14: 1 Inferences Abox 1. Inferences define(Tulio, REQ-1), Requirement(REQ-1) |= Stakeholder(Tulio) define(Davi, REQ-2), Requirement (REQ-2) |= Stakeholder(Davi) define(Tulio, REQ-3), Requirement (REQ-3) |= Stakeholder(Tulio) define(Tulio, REQ-4), Requirement (REQ-4) |= Stakeholder(Tulio) define(Tulio, REQ-5), Requirement (REQ-5) |= Stakeholder(Tulio) define(Tulio, REQ-6), Requirement (REQ-6) |= Stakeholder(Tulio) define(Tulio, REQ-7), Requirement (REQ-7) |= Stakeholder(Tulio) define(Tulio, REQ-8), Requirement (REQ-8) |= Stakeholder(Tulio) define(Tulio, REQ-9), Requirement (REQ-9) |= Stakeholder(Tulio) define(Tulio, REQ-10), Requirement (REQ-10) |= Stakeholder(Tulio) define(Tulio, REQ-11), Requirement (REQ-11) |= Stakeholder(Tulio) define(Tulio, REQ-12), Requirement (REQ-12) |= Stakeholder(Tulio) define(Tulio, REQ-13), Requirement (REQ-13) |= Stakeholder(Tulio) define(Tulio, REQ-14), Requirement (REQ-14) |= Stakeholder(Tulio) define(Tulio, REQ-15), Requirement (REQ-15) |= Stakeholder(Tulio) define(Tulio, REQ-16), Requirement (REQ-16) |= Stakeholder(Tulio) Table 18 presents the inferences for the positive-causeImpact concept. In this query it is possible to identify that requirements REQ-14 and REQ-16 have a positive impact on the requirement of REQ-15. An interesting factor with the proposed ontology is the traceability of requirements, it is possible to track which requirements have impacts on others (positive and/or negative) and describe the cause. In Requirements Engineering, traceability is an important part of the systems engineering process, as it ensures that all requirements have been carefully considered during each phase of development, and that there are no scope “gaps” in the developed system due to American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 496 missed requirements. This also ensures that all requirements are internally consistent with each other. Table 15: Inferences Abox 2. Inferences usedAt(home) (casa), uses(software-control), holds( EmergencyButton - ChampionType), Requires(REQ-1, REQ-2, REQ-3, REQ-4, REQ-5, REQ- 6, REQ-7, REQ-8, REQ-9, REQ-10, REQ-11, REQ-12, REQ-13, REQ-14, REQ-15 e REQ-16) |= AAL(PEV-Demo) System Table 16: 1 Inferences Abox 3. Inferences hasRequirement (PEV-Demo, REQ-1) |= NonFunctionalRequirement(REQ-1) hasRequirement (PEV-Demo, REQ-2) |= NonFunctionalRequirement (REQ-2) hasRequirement (PEV-Demo, REQ-3) |= NonFunctionalRequirement (REQ-3) hasRequirement (PEV-Demo, REQ-4) |= NonFunctionalRequirement (REQ-4) hasRequirement (PEV-Demo, REQ-5) |= NonFunctionalRequirement (REQ-5) hasRequirement (PEV-Demo, REQ-6) |= NonFunctionalRequirement (REQ-6) hasRequirement (PEV-Demo, REQ-7) |= NonFunctionalRequirement (REQ-7) hasRequirement (PEV-Demo, REQ-8) |= NonFunctionalRequirement (REQ-9) hasRequirement (PEV-Demo, REQ-10) |= NonFunctionalRequirement (REQ-11) hasRequirement (PEV-Demo, REQ-12) |= NonFunctionalRequirement (REQ-13) hasRequirement (PEV-Demo, REQ-14) |= NonFunctionalRequirement (REQ-14) hasRequirement (PEV-Demo, REQ-15) |= NonFunctionalRequirement (REQ-15) hasRequirement (PEV-Demo, REQ-16) |= NonFunctionalRequirement (REQ-16) Table 17: Inferences Abox 4. Inferences influence(NBR_ISO_9386-1, PEV-Demo) |= Standard(NBR_ISO_9386-1) Table 18: Inferences Abox 5. Inferences causesPositiveImpact (REQ-14, REQ-15) |= Requirement(REQ-14) causesPositiveImpact (REQ-16, REQ-15) |= Requirement(REQ-16) 6. Related Works Cameranesi [37] points out that models and methodologies capable of aiding AAL system designers during development are still lacking. Therefore, Cameranesi proposed an ontology (GoAAL) to formally represent the relevant knowledge in the AAL domain, objectives to measurements and sensors vary. Although the GoAAL ontology includes AAL elements, such as devices, stakeholders and environments, it is possible to see, according to table 19, that there is no coverage for NRF elements of any type (product quality and quality of use), ethical requirements and compliance. Villarreal [38] presents an ontology for classifying medical elements such as diseases, recommendations, preventions, food, mobile devices and diet suggestions, this ontology is called MoMOntology. Based on this ontology, an application that generates individual patient profiles, self-control and education modules for their American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 497 chronic diseases was developed. As can be seen in table 19, in MoMOntology there is no coverage for the elements of AAL system types, environment, NRF's of any kind (product quality and quality of use), ethical requirements and compliance. Mocholí [39] describes a set of ontologies created within the framework of the European VAALID project that allows the designers of Ambient Assisted Living services to model and characterize an AAL environment, the actors involved and the diverse types of spaces and devices. As can be seen in table 19, there is no coverage for the elements of types of AAL systems, NRF's of any type (product quality and quality of use), ethical requirements and compliance. Table 19: Comparison between ontologies. Ontology Types of Systems Device Enviro nments Stakehol der Product Quality NFRs Quality of Use NFRs Ethical Req Compli ance GoAAL x x x x ---- ---- ---- ---- MoMOntology ---- x ---- x ---- ---- ---- ---- VAALID ---- x x x ---- ---- ---- ---- Onto4CAAL x x x x x x x x 7. Limitations and Future Works For this survey, we identified the size of the sample used as the main limitation. Taking into consideration that the sampling method used was the non-probabilistic one, which is a method that does not define the sample size [40], since the representativeness of the population is practically impossible to measure (there is no way to determine the exact number of researchers and industry professionals working in the development of AAL systems), as well as the percentage of respondents who responded to the questionnaire. As future work, the stages of compliance with the methodology chosen for the construction of the ontology will be continued, where the stages of instaciation and evaluation, documentation and maintenance will be carried out. 8. Conclusion As it is an area with several subdomains and specificities, the development of AAL systems requires a specification of requirements that includes numerous factors involved. The challenges in developing AAL systems have led the academic community to explore and establish original approaches for the development of this type of system, such as the use of ontologies. Based on this, an ontology proposal was built, the Onto4CAAL, which can help AAL system designers in the requirements specification process, guiding on the types of AAL systems that can be developed, their area (specificity) of application, the environments, agents and devices that can be taken into account for this type of system. Ontology also makes possible to analyze which NFR's are considered, as well as to evaluate the view regarding the Compliance and NFR's relationship in AAL systems and the treatment given to the ethical requirements in these systems. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 498 Acknowledgements We would like to thank CAPES for providing the necessary resources for the elaboration of the work and the Graduate Program in Electrical Engineering (PPGEE/UFPE). 9. Conflict of Interests The authors declare that there is no conflict of interest associated with the publication of this article. References [1]. Cicirelli, Grazia, et al. "Ambient assisted living: A review of technologies, methodologies and future perspectives for healthy aging of population." Sensors 21.10 (2021): 3549. [2]. Vimarlund, Vivian, et al. "Ambient assisted living: Identifying new challenges and needs for digital technologies and service innovation." Yearbook of Medical Informatics 30.01 (2021): 141-149. [3]. Programm AAL. Disponível online: https://ec.europa.eu/eurostat/statistics-explained/index.php (acessado em 4 de julho de 2022). [4]. Cheng, D. C., Villamarin, J. B., Cu, G., & Lim-Cheng, N. R. “Towards Compliance Management Automation thru Ontology mapping of Requirements to Activities and Controls”. In 2018 Cyber Resilience Conference (CRC) (pp. 1-3). IEEE, 2018. [5]. Lentzas, A., & Vrakas, D. “Non-intrusive human activity recognition and abnormal behavior detection on elderly people: a review”. Artificial Intelligence Review, 1-47, 2019. [6]. Silva, T. G., & Alencar, F. M., “Ontologias para Sistemas AAL que abordem Compliance: um mapeamento sistemático da literature”, 2020. [7]. Gomes, T., & Alencar, F. “Análise de Ontologias para Sistemas AAL (Ambient Assisted Living) e o suporte a Compliance”, WER, 2021. [8]. Benghazi, K., et. al. “Enabling correct design and formal analysis of Ambient Assisted Living systems”. Journal of Systems and Software, 2012. [9]. Ranieri, Caetano Mazzoni, et al. "Activity recognition for ambient assisted living with videos, inertial units and ambient sensors." Sensors 21.3 (2021): 768. [10]. Machado, A., Maran, V., Augustin, I., Wives, L. K., & de Oliveira, J. P. M. “Reactive, pro-active, and extensible situation-awareness in ambient assisted living”. Expert Systems with Applications, 76, 21- 35, 2017. [11]. Nakagawa, E. Y., Antonino, P. O., Becker, M., Maldonado, J. C., Storf, H., Villela, K. B., & Rombach, D. “Relevance and perspectives of AAL in Brazil”. Journal of Systems and Sof-tware, 86(4), 985-996, 2013. [12]. Netto, C. M. “Proposta de modelo de requisitos para ferramentas de visualização de ontologia de domínio”. UFMG, 2017. [13]. Gruber, T. R. “A translation approach to portable ontology specifications”. Knowledge acquisition, 5(2), 199-220, 1993. [14]. Felicíssimo, C. H., & Breitman, K. K. “Taxonomic Ontology Alignmentan Implementation”. In WER (pp. 152-163), 2004. https://ec.europa.eu/eurostat/statistics-explained/index.php American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 499 [15]. Campos, M. L. A. “O papel das definições na pesquisa em ontologia. Perspectivas em Ciência da Informação”, Belo Horizonte, v. 15, n. 1, p.220-238, jan/abr. 2010. [16]. Vital, L. P., & Café, L. M. A. “Ontologias e taxonomias: diferenças. Perspectivas em Ciência da Informação”, 16(2), 115-130 (2011). [17]. Culmone, R., et al. “AAL domain ontology for event-based human activity recognition.” IEEE/ASME 10th International Conference on Mechatronic and Embedded Systems and Applications (MESA). IEEE, 2014. [18]. Coimbra, M.A; Manzi, V.A. “Manual de Compliance”. São Paulo: Atlas, 2010. [19]. NBR ISO 19600/2016 – “Sistema de Gestão de Compliance: Diretrizes”. ABNT, 2016. [20]. Zhong, B. T., et al. “Ontology-based semantic modeling of regulation constraint for automated construction quality compliance checking”. Automation in Construction, 2012. [21]. Jorshari, F. Z., & Tawil, R. H. “A High-Level Scheme for an Ontology-Based Compliance Framework in Software Development”. IEEE 17th International Conference on High Perfor-mance Computing and Communications, IEEE, 2015. [22]. Abran, A. et al. “Guide to the software engineering body of knowledge” (SWEBOK (R)). 3.0 ed. Los Alamitos, Calif.: IEEE Computer Society, 2004. [23]. Carvalho, E. A.; Eescovedo, T.; Melo, R. N. “Using Business Processes in System Requirements Definition”. In: 2009 33rd Annual IEEE Software Engineering Workshop, 2009. [24]. Bettaz, Mohamed, and Mourad Maouche. "Using UML-MARTE and TCOZ for AAL System Specifications: A Case Study." 2018 7th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO). IEEE, 2018. [25]. Alosaimi, Wael, et al. "Evaluating the impact of different symmetrical models of ambient assisted living systems." Symmetry 13.3 (2021). [26]. Augusto, J.C., Increasing reliability in the development of intelligent environments.In: Intelligent Environments, pp. 134–141, 2009. [27]. Erazo-Garzon, Lenin, Lourdes Illescas-Peña, and Priscila Cedillo. "A quality in use model for ambient assisted living (AAL) systems." International Conference on Applied Technologies. Springer, Cham, 2020. [28]. Nehmer, J., Becker, M., Karshmer, A., & Lamm, R. “Living assistance systems: an ambient intelligence approach”. In Proceedings of the 28th international conference on Software engineering (pp. 43-50). ACM, 2006. [29]. Rautenberg, S.; Todesco, J. L.; Steil, A. V.; Gauthier, F.A. O. Uma Metodologia para o Desenvolvimento de Ontologias A Methodology for the Development of Ontologies. Revista Ciências Exatas e Naturais, [S. l.], v. 10, n. 2, p. 237–262, 2008. [30]. Gómez-Pérez, A., et al. Ontologic Engineering: with examples from the areas of knowledge management, ecommerce and the semantic web. London: Springer-Verlag, 2004. [31]. Corcho, O.; Fernández-López, M.; Gómez-Pérez, A.. Ontological engineering: principles, methods, tools and languages. In: Ontologies for software engineering and software technology. [s.l.] : Springer, 2006. p. 1–48. [32]. Guizzardi, G. “Ontological foundations for structural conceptual models”, 2005. American Academic Scientific Research Journal for Engineering, Technology, and Sciences (ASRJETS)(2022)Volume 90, No 1, pp 476-500 500 [33]. Guizzardi, G., & Wagner, G. “Conceptual simulation modeling with ONTO-UML advanced tutorial”. In Proceedings of the 2012 Winter Simulation Conference (WSC). IEEE, 2012. [34]. Gomes, T., & Alencar, F. Um survey com especialistas como validação de elementos para composição de uma ontologia para Sistemas AAL (Ambient Assisted Living).WER, 2022. [35]. Garcés, L., et al. Quality attributes and quality models for ambient assisted living software systems: A systematic mapping. Information and Software Technology, 2017. [36]. Gomes, T. B. Projeto mecânico de uma plataforma de elevação motorizada para pessoas com mobilidade reduzida. Universidade de Brasília, 2019. [37]. Cameranesi, M., et al. "Goaal: An ontology for goal-oriented development of aal environments." Proceedings of the 31st Annual ACM Symposium on Applied Computing. 2016. [38]. Villarreal, V., et al. "Mobile and ubiquitous architecture for the medical control of chronic diseases through the use of intelligent devices: Using the architecture for patients with diabetes". Future generation computer systems 34: 161-175, 2014. [39]. Mocholí, J. B., et al. Ontology for modeling interaction in ambient assisted living environments. In: XII Mediterranean Conference on Medical and Biological Engineering and Computing 2010. Springer, Berlin, Heidelberg. p. 655-658, 2010. [40]. Kitchenham, B.; Pfleeger, S. L. “Principles of survey research”. ACM SIGSOFT Software Engineering Notes, v. 27, n. 5, p. 17-20, 2002.