nyuuzyou/wikis huggingface dataset:
Main Page

== Introduction ==
The Debug Monitor DMON is a software tool which runs on a host PC (Windows or Linux) and allows an engineer to interact with a System on a Chip via a communications link and specialised debug hardware on the SoC. It provides a view of the devices on the SoC and allows writing to and reading from memory addresses associated with those devices, and provides some high level sequences of reads and writes to perform functions on the devices.
DMON also provides several features to allow test automation through scripting and for improved visualisation of the target.
Troubleshooting

Technical support is available through the organisation from whom you purchased the product.
To ensure an efficient response please provide the following information:
# A description of the problem, if possible with a log file created using the log command, or a screen shot if it is a GUI issue.
# The exact version of DMON and the license type – this can be obtained by running the “about” command.
# The internal log file. This will usually be located in C:/Users/<user who installed DMON>/DMON/logging/dmon.internal.log on a windows machine, or ~/DMON/logging/dmon.internal.log on Linux. The location is configurable and set by the installation program. It can be checked in <DMON Installation directory>\DMON\etc\logging\log4j.properties
# A detailed description of the target hardware – which SoC and board.
# If the problem is observed in conjunction with the GDB tool additional helpful information can be gained from the communications log in GDB. To get such a log, issue the command “set remotelogfile <filename>” before connecting to DMON with “target extended-remote”
Guia de estilo

== Pense em 'enciclopedia' e não em 'revista' ==
Atenha-se aos fatos. Adote uma posição neutra. Não expresse sua própria opinião.
Você não precisa ser "amigável" - isso não é um blog.
Artigos não são uma oportunidade para auto-promoção. Você pode incluir o máximo de autopromoção que quiser na sua "página sobre mim", mas não no seu artigo. Para permanecer imparcial, pergunte a si mesmo o que outra pessoa escreveria sobre o assunto.
Mesmo se você estiver escrevendo sobre seus próprios produtos ou projetos, escreva sobre eles na terceira pessoa. Você nunca deve precisar escrever "eu" ou "nós" em um artigo.
Seja equilibrado. Se você listar as vantagens, liste também as desvantagens. Se listar os prós, também liste os contras.
== Torne seu artigo acessível ==
Dê ao seu artigo um título simples e direto. Apenas diga o que é.
Apresente seu assunto. Qual é o pano de fundo?
Explique os termos técnicos mais especializados e siglas.
Evite parágrafos longos. Eles são difíceis de ler.
Use listas de marcadores para tornar as informações claras e acessíveis.
Não use letras maiúsculas, a menos que sejam absolutamente necessárias. A capitalização torna o texto difícil de ler.
Para uma orientação mais geral sobre redação, consulte nosso manual de redação.
== Conteúdo duplicado ==
 
 Seu artigo receberá mais tráfego se for único e adaptado aos requisitos específicos do público do ConstruWiki.
 Nós permitimos que você publique conteúdo que já aparece em outro lugar na internet, como artigos que aparecem em seu próprio site. No entanto, os mecanismos de pesquisa podem categorizá-lo como "conteúdo duplicado" e, portanto, podem não incluí-lo nos resultados de pesquisa. Isso reduzirá significativamente a quantidade de tráfego que o artigo recebe.
 Onde você publica conteúdo duplicado, inclua um link para a fonte original.
== Como usar o editor de texto ==
Mantenha sua formatação o mais simples possível. Texto sem formatação, cabeçalhos e listas com marcadores. Colar texto com formatação mais complexa pode confundir o editor de texto.
Salve seu trabalho regularmente.
Para mais informações, consulte a nossa página de ajuda.
Política editorial

O ConstruWiki é uma plataforma de acesso aberto. Você é livre para escrever artigos sobre qualquer assunto relacionado ao setor de construção civil, desde o planejamento e o estudo de viabilidade até a construção, operação e descomissionamento. Você pode escrever sobre teoria, práticas, procedimentos, produtos, serviços, projetos e até empresas. Tudo o que pedimos é que os artigos sejam factuais e equilibrados(ou seja, não sejam mera peças promocionais) e adotem um estilo enciclopédico (ou seja, não sejam posts de blog). Consulte nosso Guia de estilo para mais detalhes
.
Os artigos que você criar estarão disponíveis no site a partir do momento em que você clicar em "Salvar". Não temos processo de aprovação e envio, no entanto, verificaremos todos os novos artigos e todas as edições subsequentes para garantir que eles estejam em conformidade com nossas diretrizes editoriais e de estilo. Os artigos que não estão em conformidade podem ser editados ou, em casos extremos, podem ser excluídos e edições inadequadas serão desfeitas.
Se você é um especialista e não deseja que outras pessoas alterem o seu artigo, você pode protegê-lo. Se recebermos solicitações de outros usuários que queiram contribuir com o artigo, podemos, eventualmente, cancelar sua proteção, mas discutiremos isso com você primeiro.
Página principal

Welcome to Wikipedia,
the free encyclopedia that anyone can edit.
 articles in English
Arts
Biography
Geography
History
Mathematics
Science
Society
Technology
All portals
Did you know...		
In the news
On this day
Other areas of Wikipedia
Wikipedia's sister projects
Wikipedia languages
__NOTOC__
Análise de desempenho de edifícios
Arquitetura bioclimática tropical
Público em geral:Sua casa sustentável/Projeto
Público em geral:Sua casa sustentável/Projeto/Projeto bioclimático
Teste:SCS/Projet/Projet bio
Teste:SCS/Projet

Projeto
Design
Teste:SCS/Projet/Projet bio
Teste:SCS/Projet/Orientation
Teste:SCS/Projet/Shading
Teste:SCS/Projet/Passivheat
Teste:SCS/Projet/Passivcool
Teste:SCS/Projet/Seal
Teste:SCS/Projet/Insul
Teste:SCS/Projet/Insulinst
Teste:SCS/Projet/Thermass
Teste:SCS/Projet/Glaz
Teste:SCS/Projet/Skyl
1. Selectielijst voor gemeenten en intergemeentelijke organen 2020

Categorie:Duurzame toegankelijkheid
 __NOTOC__
==1. Inleiding==
Dit is de handreiking die hoort bij de Selectielijst gemeenten en intergemeentelijke organen 2020 (verder: Selectielijst 2020). De Selectielijst 2020 vervangt de selectielijst 2017. De Selectielijst 2020 is opgesteld naar aanleiding van wetten die na de vaststelling van de Selectielijst 2017 van kracht zijn geworden. Een aantal correcties is aangebracht en omissies recht gezet. Daarnaast zijn er nieuwe risicoanalyses uitgevoerd waarbij specifiek is gekeken naar de effecten van de Algemene verordening gegevensbescherming (AVG) op een aantal bewaartermijnen. Tot slot zijn enkele nieuwe categorieën toegevoegd, waaronder bewaartermijnen voor algoritmes. Alle wijzigingen ten opzichte van de Selectielijst 2017 zijn opgenomen in Bijlage 8 van de Selectielijst 2020.
De Selectielijst 2020 heeft een procesgerichte opzet en is sector- en domeinonafhankelijk. Waar men vroeger bij het selecteren van archieven keek naar het taakveld dat werd uitgevoerd, dient nu gekeken te worden naar het uitgevoerde proces. Documentgerichte selectie wordt vervangen door procesgerichte selectie. Een informatie-element staat (bijna) nooit op zichzelf, maar maakt deel uit van een proces of zaak, waarbij het proces of de zaak als geheel (inclusief alle archiefbescheiden) wordt gewaardeerd.
In deze handreiking leest u hoe de nieuwe selectielijst gelezen en gebruikt moet worden. Ook geeft de handreiking tips hoe de selectielijst ingezet kan worden in uw organisatie.
Deze handleiding gaat in op de praktische uitwerking en implementatie van de selectielijst. Een gedetailleerde beschrijving van de opzet en methodiek van de selectielijst kunt u vinden in hoofdstuk 1 van de Selectielijst 2020.
De handreiking is bedoeld voor iedereen die de Selectielijst 2020 in de praktijk moet toepassen en nadere uitleg wenst over opzet en uitwerking ervan.
7. Risicoanalyse

Categorie:Duurzame toegankelijkheid
 __NOTOC__
===7. Risicoanalyse===
Daar waar de systeemanalyse en trendanalyse zich richten op permanent te bewaren archiefbescheiden, richt de risicoanalyse zich op vernietigbare archiefbescheiden. De risicoanalyse is de basis voor alle bewaartermijnen voor vernietigbare informatie, mits deze niet wettelijk is bepaald.
Risicoklasse	Bewaartermijn
Klasse 1 	1 jaar
Klasse 2 	5 jaar
Klasse 3 	10 jaar
Klasse 4 	20 jaar
Klasse 5 	50 jaar
Tabel 1. De bewaartermijnen per risicoklasse
De risicoanalyse heeft als doel: het bepalen van belang van informatie-elementen voor de bedrijfsvoering van de zorgdrager. Hiermee wordt bedoeld dat alle informatie die een overheidsorgaan beheert, moet worden beoordeeld op de waarde voor de organisatie. Er moet een inschatting worden gemaakt wat het risico voor de organisatie is, als bepaalde informatie niet meer aanwezig is of juist nog wel aanwezig is terwijl deze informatie allang vernietigd had moeten zijn.
Het begrip risico wordt omschreven als:
Risico is het potentiële nadeel dat de organisatie ondervindt door het al dan niet beschikbaar hebben van haar archiefbescheiden. Het gaat om het belang van de informatie voor de zorgdrager zelf.
De risicoanalyse is vertaald naar tabel 1. Op basis van de ingeschatte risico’s kan een proces kan geschaard worden onder één van vijf mogelijkheden die de risicoanalyse biedt.
Een proces of zaaktype dat op basis van de systeemanalyse, trendanalyse en/of wet- en regelgeving niet voor permanente bewaring in aanmerking komt, kan uitsluitend één van de vijf beschikbare bewaartermijnen krijgen. Het is dus niet mogelijk dat een proces op basis van de risicoanalyse gewaardeerd wordt op een bewaartermijn van bijvoorbeeld 3 of 7 jaar.
In de praktijk betekent dat dat er gekeken wordt naar de waarde van bepaalde informatie voor de organisatie en dat op basis van die waardering wordt voor één van de vijf categorieën van de risicoanalyse. De waarde van informatie wordt bepaald door de ervaring die informatiemedewerkers hebben en door gesprekken te voeren met proceseigenaren.
In het kort komt het neer op volgende uitgangspunten:
* 1 jaar: Informatie heeft geen of beperkte waarde voor de organisatie
* 5 jaar: de organisatie heeft de informatie nodig voor een beperkte periode
* 10 jaar: de organisatie heeft de informatie lang nodig voor de bewijs- en/of bedrijfsvoering, vaak vanwege mogelijke juridische consequenties.
* 20 jaar: de organisatie heeft de informatie lang nodig om bepaalde processen uit te kunnen voeren
* 50 jaar: de organisatie heeft informatie lang nodig omdat er sprake is van een lange aansprakelijkheids- c.q. verjaringstermijn. Dit speelt met name een rol in milieu- en bodemsaneringszaken en in contacten met gevaarlijke stoffen.
8. Productinformatie en discussie

Categorie:Duurzame toegankelijkheid
 __NOTOC__
===8.1 Excellijst===
Bij de publicatie van de selectie stelt de VNG, naast de selectielijst in pdf-formaat, een excel-versie van de selectielijst ter beschikking. Deze lijst kan worden gebruikt om selecties uit te voeren door gebruik te maken van de filtermogelijkheden, bijvoorbeeld door te filteren op taakveld zoals de GEMMA die vermeldt. Daarnaast kunnen intergemeentelijke organen in deze lijst resultaten verwijderen die niet op hun organisatie van toepassing zijn. 
Alle organisaties kunnen de excel-versie gebruiken om aantekeningen te maken door bijvoorbeeld zaaktypen te koppelen aan specifieke resultaten.
===8.2 SelectTool===
Begin maart 2020 is door de VNG via de website van de VNG een gratis softwareprogramma beschikbaar gesteld: de SelectTool 2020. In deze tool wordt de nieuwe selectielijst weergegeven waarbij per resultaat alle essentiële informatie wordt weergegeven. Deze tool is doorzoekbaar en zal per resultaat ook een vergelijking met de Selectielijst 2012 bevatten. Als bijlagen bij deze tool worden de Selectielijst 2012, de Selectielijst 2017, de Selectielijst 2020 en een concordans tussen de drie lijsten worden meegeleverd.
===8.3 Informatie en discussie===
VNG
Voor vragen en opmerkingen over de selectielijst kunt u terecht op het VNG forum Selectielijst archiefbescheiden. U moet zich daarvoor wel inschrijven en aanmelden. U krijgt dan een reactie van de Adviescommissie Archieven.
BREED
Op het forum van BREEDnetwerk.nl worden verschillende discussies gevoerd over de Selectielijst 2020. Daarnaast kunnen use cases en gezamenlijk uitgewerkte toepassingshandleidingen (bijvoorbeeld voor publieke gezondheid en veiligheidsregio’s) goed gedeeld kunnen worden via https://kia.pleio.nl.
VHIC
VNG en VHIC hebben afgesproken dat u voor (korte) praktische vragen en inhoudelijke opmerkingen ook terecht kunt bij VHIC. U kunt vragen stellen aan de digitale consultant van VHIC: Zaalberg. U kunt de vragen en opmerkingen sturen naar zaalberg@vhic.nl. U krijgt dan antwoord van adviseurs die betrokken zijn geweest bij de opstelling van de selectielijst. Een selectie van de vragen die via dit mailadres binnen komen, worden gepubliceerd in het blad van VHIC, Sited. Als u dit digitale blad wilt ontvangen kunt u contact opnemen met VHIC onder kcc@vhic.nl.
API-standaarden

Het wordt steeds belangrijker voor (applicatie)componenten om onderling goed samen te werken. Om dit mogelijk te maken kennen componenten (applicatie)services die voor andere componenten toegankelijk zijn via zogenaamde 'Application Programming Interfaces' (API's). Zo kunnen componenten op een gestructureerde manier functionaliteit van andere componenten gebruiken. Bijvoorbeeld door een API aan te bieden die voor andere componenten bruikbaar is om gegevens uit een achterliggende bronregistratie te gebruiken.
Om doelmatig en efficiënt met API's te werken is het belangrijk om de manier waarop API's worden ontwikkeld, gedocumenteerd, getest en werken te standaardiseren. Er zijn een aantal manieren om dit te realiseren. Een daarvan is het kiezen voor een bepaalde architectuurstijl. Net als in de rest van de wereld geldt ook voor de Nederlandse overheid dat de voorkeur momenteel uitgaat naar API's die werken volgens de REST-architectuurstijl. Maar dan nog geldt dat er aanvullende ontwerpkeuzes moeten worden gemaakt. Daarom is afgesproken om overheidsbrede afspraken te maken over hoe de REST-stijl wordt toegepast bij het ontwerpen van API's. Deze afspraken zijn vastgelegd in de REST-API Design Rules standaard.
Op de website developer.overheid.nl is te zien dat er steeds meer overheids-API's beschikbaar komen die allerlei soorten functionaliteit aanbieden. Op data.overheid.nl worden (ook) API-specificaties gepubliceerd waarmee open data is op te vragen. Voor gemeenten zijn met name API's interessant waarmee elders vastgelegde brongegevens toegankelijk worden gemaakt. Gebruik daarvan kan bijvoorbeeld leiden tot hogere actualiteit en betrouwbaarheid van data en het onderhouden van lokale kopieën overbodig maken. 
De GEMMA Architectuurvisie beschrijft hoe standaardisatie via het gebruik van API's cruciaal is om toe te kunnen werken naar een fundamenteel betere informatievoorziening voor gemeenten. Iets dat verder wordt uitgewerkt binnen de thema-architectuur Common Ground die de architectuur uitwerkt die nodig is om de doelen van Common Ground te realiseren. 
Vanuit de VNG wordt op verschillende manieren gewerkt aan de ontwikkeling van gestandaardiseerde API's: 
* Via het programma HaalCentraal is gewerkt aan het ontwikkelen van de HaalCentraal API's zodat gemeenten beter data kunnen opvragen uit de basisregistraties. 
* Het project Notificatieservices heeft een concept-standaard ontwikkeld voor het notificeren van plaatsgevonden gebeurtenissen, zoals het wijzigen van brongegevens, aan daarop geabonneerde afnemers. Deze NL GOV for CloudEvents standaard is nu in beheer bij Logius. 
* Voor ondersteuning van zaakgericht werken binnen gemeenten zijn API-standaarden voor zaakgericht werken ontwikkeld.
Category:Standaarden paginas
API Capability Model

Categorie:Werken met APIs
__NOTOC__
Als organisatie beschikken over de benodigde bekwaamheden vereist maatregelen die zowel de bedrijfs-, informatie- als technische architectuur raken. Op organisatorisch gebied moet bijvoorbeeld zijn geregeld dat taken en verantwoordelijkheden rondom aanbieden en gebruik van API's goed zijn belegd. Binnen de informatievoorziening moeten voorzieningen API's kennen die verantwoord zijn te gebruiken. Tot slot moeten technologische voorzieningen het mogelijk maken om snel en veilig toegang tot API's te krijgen. 
Binnen de Nederlandse API Strategie is een 'API Capability Model' ontwikkeld dat beschrijft aan welke onderwerpen men aandacht moet schenken bij het werken met API's. Het model bevat generieke functies, of capability's, waarover een organisatie moet beschikken om verantwoord en effectief API's aan te bieden en gebruiken. Daarbij geldt dat generieke functies beschrijven wat er nodig is. Niet hoe en functie moet worden gerealiseerd.
Binnen het model zijn generieke functies gegroepeerd in 3 categorieën:
*Registratie & gebruik: functies voor het ondersteunen van ontwikkelaars die gebruik willen maken van de aangeboden API's.
*Realisatie & beheer: functies voor het (door)ontwikkelen van API's, het beheren van API lifecycles en het beheren van het API ecosysteem.
*Verkeersstroom beheer: functies die te maken hebben met verwerken van daadwerkelijk verkeer tussen de API client en aanbieder en het verwerken daarvan binnen het API landschap.
 
Onderstaande tabel toont per categorie de onderscheiden generieke functies. 
Generieke functies binnen het API Capability Model van de NL API Strategie
Registratie & Gebruik 	Realisatie & Beheer 	Verkeersstroom beheer
Ontwikkelaar onboarding 	Ontwerp 	Mediatie & Orkestratie
Applicatie registratie 	Ontwikkeling 	Routering
API Discovery 	Test 	Data Transformaties
Specificatie & Documentatie 	Policy Definitie 	Foutafhandeling
Proeftuin / Sandbox 	Afspraken, Standaarden en Richtlijnen	Caching
Code voorbeelden & SDK 	Governance policy handhaving 	Protocol conversie
Kennisdeling & Ondersteuning	API Lifecycle beheer 	Logging & Audit trail
 	Versionering 	Monitoring & Alerting
 	Toegangsbeheer 	Analytics & Dashboarding
 	Gateway beheer 	0Rate limiting / throttling
 	Sleutelbeheer 	Doorbelasting
 	 	Identificatie & Authenticatie
 	 	Autorisatie
 	 	Policy handhaving
 	 	Anomalie detectie
Het model laat zien dat er veel verschillende soorten functies zijn die van belang (kunnen) zijn bij het werken met API's. Uiteraard geldt dat niet iedere functie voor iedere organisatie relevant is. Een organisatie die geen API's aanbiedt, maar alleen API's afneemt hoeft een aantal functies niet te realiseren. Maar in alle gevallen blijft het belangrijk om om te beseffen dat toenemend gebruik van API's het noodzakelijk maakt om als organisatie aandacht te besteden aan hier genoemde onderwerpen. 
Een beschrijving van het API Capabilty Model en van de daarin opgenomen generieke functies is te vinden in de module 'Architectuur' van de NL API Strategie.
Applicatieservices

Categorie:Informatie-architectuur
Binnen een servicegeoriënteerde architectuur spelen diensten/services een centrale rol. In veel situaties is het nuttig om te denken in termen van services zonder dat meteen duidelijk hoeft te zijn door welke componenten een service wordt gerealiseerd. Bijvoorbeeld bij het opstellen van een doelarchitectuur of bij het gebruik van Cloud-voorzieningen waar bij af te nemen services vaak onbekend is door welke componenten ze worden gerealiseerd. Onderstaand model toont de generieke gemeentelijke applicatieservices en ordent die naar doelgroep en genericiteit.
ArchiMate modelleren

Category:ArchiMate modelleren
Category:Modelleren handleidingen‎
__NOTOC__
Voor het beschrijven van de GEMMA wordt intensief gebruik gemaakt van architectuurmodellen. Onder een architectuurmodel verstaan we: 'Een representatie van een systeem(onderdeel) met behulp van modelmatig geordende elementen'. Modellen helpen om op een gestructureerde manier een systeem (of onderdeel daarvan) te beschrijven. Een eenmaal ontwikkeld model is voor meerdere doelen bruikbaar en is op basis van nieuwe inzichten te onderhouden en uit te breiden. GEMMA architectuurmodellen worden gemaakt met ArchiMate: een open en onafhankelijke modelleertaal architectuur, ondersteund door meerdere architectuurtools. 
Voor een toelichting op het verschil tussen 'tekenen' en 'modelleren' zie Tekenen en modelleren.
De GEMMA kent een drietal modellen die openbaar toegankelijk op Github worden gepubliceerd:
* Het 'GEMMA Archimate model': het architectuurmodel met alle binnen de GEMMA benoemde architectuurelementen, relaties en views. Dit model wordt onder andere gebruikt om op GEMMA Online getoonde views te genereren en om binnen de GEMMA Softwarecatalogus relaties te leggen tussen opgenomen softwarepakketten en GEMMA referentiecomponenten en standaarden. Naast onderhoud en doorontwikkeling van de GEMMA, is het model bruikbaar voor gemeenten en leveranciers als basis voor eigen architectuurproducten.
* Het 'GEMMA Kennismodel': het model dat de GEMMA architectuurelementen en hun onderlinge samenhang beschrijft. De inhoud van het model wordt op GEMMA Online weergegeven op de pagina GEMMA Kennismodel.
* Het 'GEMMA Portfolio' model: dit model bevat de verschillende GEMMA-producten en hun relaties. De inhoud ervan wordt op GEMMA Online weergegeven op de pagina GEMMA Portfolio.
ArchiMate modellen worden door het Kenniscentrum Architectuur van VNG Realisatie ontwikkeld en onderhouden. Daarbij wordt gebruik gemaakt van de open source architectuurtool Archi. Voor versiebeheer en samenwerken aan ArchiMate modellen maakt Archi gebruik van de tool git. 
Architectuurmodellen worden op Github gepubliceerd in repositories van VNG Realisatie. Gemeenten en leveranciers kunnen Archi gebruiken om de GEMMA Archimate modellen te koppelen of te importeren. Het is ook mogelijk om via gebruik van de AMEFF-uitwisselstandaard GEMMA modellen te importeren in andere architectuurtools zoals BiZZdesign, Mavim, Sparx en Value Blue.
Het op deze manier publiceren en delen van GEMMA architectuurmodellen maakt het mogelijk dat meerdere partijen gelijktijdig kunnen werken aan doorontwikkeling van de GEMMA en dat gemeenten en leveranciers de GEMMA modellen kunnen gebruiken voor eigen doeleinden. 
Via onderstaande verwijzingen is meer informatie te vinden over gebruik van de GEMMA modellen en het werken met Archi.